半年ぐらい掛けて、少しずつ、ひっそりと、サイトをリニューアルしたので、その時のメモです。
当初は簡単なメモだったのですが、いつの間にかメモと言うには量が多くなってしまいました。 眠らせておくのも勿体ないのでまとめて公開します。
少し長いので（最近はむやみに記事が長い気がしますが）、最初に主な内容を書いておきます。
主に上記4つの内容となります。
HTMLとCSSは本職ではないのですが、ちょっと頑張りました。
上記のような事を目的にリニューアルしました。
上記でサポートされている技術を基本とする。
IEは出来るだけ対応するものの、その個性は尊重する。 (リニューアルにもたついている間に、IE8が出てしまいましたが、IE8は割と大丈夫そうです)
ちなみに当サイトのブラウザ比率は、以下のような感じです。
browser on Flickr - Photo Sharing!
browser-os on Flickr - Photo Sharing!
とある期間の比率ですが、圧倒的にFirefoxが多いです。次いでIEと、Chromeも少し、Safariはマカーの影響が高そうです、OperaはChromeにシェアを奪われていそうです。
Style none on Flickr - Photo Sharing!
ここから実作業です。まず一番始めに、HTMLの組み立てから行いました。
HTMLのコーディング時に行った事を、順番に書いていきます。
一からデザイン出来る程、デザイン力はないので、適当にテンプレートを眺めながら、好みのデザインを探しました。
いつもなら、テンプレートのデザインはそのままに、HTMLとCSSだけ組み替えるのですが、今回はデザインテンプレートを参考にしながら自分で作っていきました。
デザインを考えていたのは随分前なので、今となってはどれを参考にしたか分からなくなってしまいました:)
参考までに、過去のエントリや僕のブックマークへのリンクを張っておきます。
デザインは大体決まったので、表示に必要な情報を整理してまとめたあと、 論理構造を意識しつつ、それらを簡単にマークアップしました
CSSを書きながらその都度idやclassを割り振っていると、煩雑になりがちなので、 構造を考えた上で、CSSを書く前にidとclassを割り振っておきます。
最近はidよりclassの方がいいんじゃないかと思っています。 例えば、サイトタイトルとエントリタイトルとがあった時に、
<div id="site">
<div id="site-title">サイトタイトル</div>
</div>
<div id="entry">
<h1 id="entry-title">タイトル</h1>
</div>
<style>
#site-title{
/* style */
}
#entry-title{
/* style */
}
</style>
とするよりも
<div class="site">
<div class="title">サイトタイトル</div>
</div>
<div class="entry">
<h1 class="title">タイトル</h1>
</div>
<style>
.site .title{
/* style */
}
.entry .title{
/* style */
}
</style>
とした方が分かりやすいのではないかと。html中で使用するclassはシンプルで短くなるし。
idは全く使わない訳ではなくて、ヘッダーやフッター等、構造上一つしか出てこない要素にはidを付けるし、 JavaScriptの都合上、idを付けておいたほうが楽な時は、idを割り振っておく。
classだけでもCSSは難なく組めるけど、JSから扱う時は、classだけだと少し辛い。 livedoorだったと思うけど、HTMLのidはプログラマーのもの、classはデザイナーのものと言う話をどこかで聞いて、「なるほど」と思いました。
HTMLを組む時に、head要素はあまり気にしてこなかったのですが、入れておくと少し幸せになれそうなものを入れておきました。
セマンティックWebの分野は全然詳しくないのですが、Webページのメタデータの整備はどんどん進んでいくのだと思います。
canonicalは正しいURLを示すlink要素として、定義します。
<link rel="canonical" href="http://blog.37to.net/" />
これを使うと、パーマリンクを明示的に指定する事が出来ます。Webのコンテンツとして一意なURLを示すことが出来るのは、 SEOというよりも、SBMやフィードリーダー等、あらゆるウェブサービスで利用出来る価値が、URLの正規化にはあると思います。
詳細は以下の記事をご参照下さい。
検索エンジン3社が開始した、rel=canonicalの使い方 ::: creazy photograph
MTで書くと以下みたいな感じです。
<link rel="canonical" href="<$mt:EntryPermalink$>" />
link要素のrel="next"、rel="prev"を加えるとブラウザによるナビゲーションのサポートが期待できます。
一番大きいのはAutoPagerizeに対応出来る事だと思います。（Operaはデフォルトで何かしてくれた気がする）
MTなら以下のように書きます。
<MTEntryPrevious><MTIf tag="EntryPermalink"><link rel="prev" href="<$mt:EntryPermalink$>" title="<$mt:EntryTitle$>" /></MTIf></MTEntryPrevious> <MTEntryNext><MTIf tag="EntryPermalink"><link rel="next" href="<$mt:EntryPermalink$>" title="<$mt:EntryTitle$>" /></MTIf></MTEntryNext>
AutoPagerizeで使うにはもう少し工夫が必要なので、以下のリンクを参照して下さい。
Movable Type 4.1をAutopagerizeに対応させる - WEBデザイン BLOG
KANZAKI先生の所を参考にしました。
ヘッダーやフッタ、メインカラムはdivを使いがちだったのですが、構造として組んでおきたいと思い、 リストで組んでみました。
HTML5で組めるようになるまではこれでいこうかと思います。
イメージとしては以下のようなコードです。
<ul id="header">
<li class="title">サイトタイトル</li>
<li class="description">デスクリプション</li>
</ul>
<ul id="contents">
<li class="entry">
<h1 class="title">タイトル</h1>
<p>本文</p>
</li>
<li class="comment"></li>
<li class="trackback"></li>
</ul>
<ul id="footer">
<li class="copylight"></li>
</ul>
一通りHTMLが組めた所で、CSSのコーディングに入ります。
CSSの分割は賛否両論ですが、今回は用途毎に複数分割しました。
段階を追ってCSSを組むときに、そのまま順番に触る内容に合わせています。 CSSの組み込み過程はスクリーンショットにとっておきましたので、順番に記載していきます。
せっかくなので1〜2年前に話題になっていた、エラスティックレイアウト(参考：ウノウラボ Unoh Labs: エラスティック・レイアウトのご紹介)にしようと思ったのですが、 よくよく考えると、今日では主要ブラウザにズーム機能が実装されてしまい、 わざわざ実装する必要がないという事に気付きました。
ズーム機能は別にしたとして、文字サイズを変えるとレイアウトが崩れないのはいいのですが、 横スクロールバーが出るのは、エラスティックレイアウトの微妙な所だと思います。
加えて、最近はスマートフォンなどのモバイル端末、UMPC等、閲覧環境が今まで以上に多彩化してきています。 各端末毎に最適化出来ればいいのですが、個人のサイトでブラウジング環境毎に処理を変更するのはなかなか大変です。
参考までに、Google Analyticsで取得した解像度の情報を張ってみます。
resolution on Flickr - Photo Sharing!
横は1280pxが少し多いものの、基本的には上記の通り、バラバラです。
どうしようかと考えた結果、エラスティックレイアウトはやめて、 emベースのレイアウト + max-widthでwindow幅を超えさせないという形にしました。
実装したポイントは、本文を読みやすくする事を最優先に、余った部分へナビゲーションを配置し、 閲覧環境に合わせて柔軟にレイアウトが変わるようにしました。
図にすると以下のような感じで、閲覧環境によって、3カラム、2カラム、1カラムと可変になります。
| 大きな文字 | 小さな文字 | |
|---|---|---|
| 広いウィンドウ | ||
| 狭いウィンドウ |
という感じで指定しています。
唯一の欠点は、IE以外でメインカラムの高さが少ない（本文の量が少ない）時に、 ナビゲーションがサイドと、メインカラム下部の、二つに分散されてしまう事です。 以下のような感じです。
layout_5 on Flickr - Photo Sharing!
margin-bottom : -32768px; padding-bottom : 32768px;
とか、偽装絶対指定も試してみましたが上手くいかず、CSSでの解決は無理そうなので、とりあえず現状では放置しています。
あと、右サイドのカラムについて、IE7ではhaslayoutの絡みでサイドのボックスが上手く回りこまず、 他のブラウザよりもメインとナビゲーションの隙間が空いてしまいました。 仕方ないので、CSSハックを使い、ネガティブマージンを指定して対応しました。
その他参考
前述のレイアウトを実装するに当たり、最初はメインカラムとサイトナビゲーションの両方をfloat:leftで実装していました。
floatでの実装は問題があって、ウィンドウの幅が狭く、ナビゲーションのボックスがメインコンテンツの下に回り込んでいた時に、 ボックスが横並びになるのですが、各ボックスの高さが違う為、途中で引っかかったりすると、残念な事になります。
色々調べていて見つけたのが、CSS2.1で定義されているdisplay:inline-blockです。
簡単に説明すると、要素の幅や高さを変更出来るinline要素として扱う事が出来ます。 これを使うとvertical-alignを利用したり、floatを使ってボックスを横並びしていた所に適用出来ます。
現在はIE以外の主要ブラウザでは特別な定義なく使用が可能で、IEは少し工夫してやると同様の事が可能になります。
inline-blockの詳細は以下の資料が分かりやすく、非常に良くまとまっています。
書籍などに紹介されていない display : inline-block について
floatやpositionを利用したレイアウトに加え、恐らく今後は新しいレイアウト手法として、広がっていくと思います。 さらに以下のエントリも併せて読むと、inline-blockへの理解が深まります。
Kanasan.JS JavaScript 第 5 版読書会 #7: Days on the Moon
ネックだったFirefox2向けの指定は、-moz-inline-boxの他にも、-moz-box-flexを使う方法もあるようです。 （そもそもFirefox2自体はサポートが切れているので、対象にしなくても良いかも知れません）
IEはdisplay:inlineとzoom:1を使わなくても、display:inline-blockを定義した後に、もう一度display:inlineを定義すれば出来るようです。 上記にはサンプルコードも記載されているので、併せてご覧になられると、よく分かると思います。
display:table-cellも使えるようになれば、さらにレイアウト手法が広がるのですが、残念ながらIEは8からのようで、 IE8のリリースと、バージョンが上がったIEの浸透率を考えると、利用できるのは数年先になりそうです。
色々とアイコンを使っているのですが、フリーのアイコンを落としてきたのが随分前で、 今となってはどこから落としたのか分かりません:)
検索すれば色々出てきますが、参考までに僕のdel.icio.usへのリンクを張っておきます。
タグ付けが整理出来てなくて、「icons」と「icon」がありますが、そっとしておいて下さい。
あと、livedoor Readerとdel.icio.usのフィードアイコンを少し自作したのですが、これが個人的にはお気に入りです。
単純にフィードアイコンとfaviconをくっつけただけですが、なかなかいいアイデアじゃないかと自負しています。
今までちゃんと考えた事がなかったので、これを機に少し考えてみました。
検索すればすぐに見つかりますが、以下のリンクがとても参考になります。
詳細なコードはリンク先を参考にして頂くとして、上記のリンクの中で一つ興味深い事がありました。
印刷用CSSはmediaタイプを使って、印刷に適した形にデザインを変更する事になります。
そこで疑問になるのが、見ているページそのまま印刷されると考えるユーザーが多いのではないか？
もしそうなら、見ているページと違うデザインが印刷の際に出てくるのは、ユーザーから見てどうなんだ？
という議論があり、少し考えてみました。
結果的には、そのサイトのターゲットがどのような層を想定しているかで、対応が変わってくると思いますし、 結局はユーザービリティテストを重ねて、よりベターな方法を取るのがよいのだと思いました。
個人的に思ったのは、ユーザーは見ているページと同じデザインで印刷される事を想像しているかも知れません。 ですがそれ以上に、目的の情報がより見やすく印刷される事を求めているのではないかと思いました。
ちゃんとしたもの作ろうとすると、意外に難易度が高かったので、今回は不要なナビゲーションの排除と、 見出しにボーダーを付けるぐらいに留め、細かい表示自体はブラウザに任せるようにしました。
デザインがある程度出来た所で、サイトの構築に入ります。
当初はPythonのフレームワーク、Djangoを使いたかったので、Django製のブログツールを使うか、自作しようと考えていたのですが、 借りているサーバー環境が貧弱なので断念。
無難に今まで使っていたMovableType3.2を、当時は最新の4.24へバージョンアップする事にしました。
アップデートの場合は、基本的にバックアップを取った上で、上書きインストールで大丈夫（バックアップは取るべき）ですが、バージョンの差異が大きいので、以下のようにしてインストールしました。
MT3.2から、4.2にアップしたのですが、テンプレートが保存出来なかったりと、どこか挙動がおかしかったです。
対応としては、既存のテンプレートをバックアップした上で、新規テンプレートセットを適用する事で直りました。
Smartyでもよく使うのですが、djangoライクというか、railsライクなテンプレート管理です。
MT3系でテンプレートを管理していると、ヘッダーモジュールにbody要素の開始タグがあり、 フッターモジュールに終了タグがあるというような、開始タグと終了タグが別々のテンプレートに存在するという事が、 必然的に起こっていました。
MT4.2ではMT3.2にはなかった変数が使える上に、MTIncludeBlockや、MTSetVarBlockが使えるので、そういう煩わしさから解放されます。
分割形と内包形の違いはウノウラボ Unoh Labs: SmartyでRailsライクなレイアウトテンプレートを使う を見てもらえると分かりやすいと思います。
ここではMTでのサンプルコードを書いておきます。
<mt:IncludeBlock module="base">
<mt:SetVarBlock name="title"><$mt:EntryTitle encode_html="1"$></mt:SetVarBlock>
<mt:SetVarBlock name="main_contents">
<div id="title">タイトル</div>
<div id="entry">本文</div>
</mt:SetVarBlock>
</mt:IncludeBlock>
<html>
<head>
<title><mt:var name="title"></title>
</head>
<body>
<div id="header">
</div>
<div id="main">
<mt:var name="main_contents">
</div>
<div id="footer">
</div>
</body>
</html>
サンプルコードを見て頂くと分かると思うのですが、レイアウトのベースが一つのテンプレートに収まり メインコンテンツの部分は変数になっています。
このような形にする事で、HTMLからテンプレートに落とす時も作業が行いやすく、 無駄にテンプレートを増やさないので見通しもよくなり、効率よくテンプレートの管理が出来ます。
コメントテンプレートはややこしいので、MTの仕様を正しく理解していないと、すぐにコメントが動かなくなってしまいます。
MT3.2の時にもはまっていたのに、懲りずにまた悩んでしまいました。
結局、コメントのテンプレートはデフォルトのものをそのままincludeするようにしました。
コメントのテンプレートは、MTのバージョン毎に仕様が違うので、そのバージョンでのデフォルトを使います。
また、デフォルトでインデックステンプレートに作られるmt.jsもscript要素で読み込むようにしなければ、 コメントのフォームが動かなくなってしまいます。
加えて、このテンプレートの内容はブログ毎に内容が変わるので、複数のブログがある場合は、ブログ毎に生成されたmt.jsを読み込む必要があります。
テンプレートを作成していると、用途毎にパーツが分かれてきます。 修正の度に目的のテンプレートまで画面遷移していると、とてつもなく時間が掛かるので、 テンプレート一つにつき、一つのタブを開いていました。
多いときはMTの管理画面だけで30個ぐらいタブを開いたりしていたのですが、通常のブラウザだと酷い事になります。
そんな時はFirefoxと、その拡張のツリー型タブ (Tree Style Tab) :: Firefox Add-onsの出番です。
Movable Type editing shot on Flickr - Photo Sharing!
こんな調子でサイト毎×テンプレート数の分だけタブを開いてました。欠点はメモリを食う事と、Firefoxが落ちた後にセッションを回復しようとすると、とんでもない事になります。
相変わらず分かりにくいという印象です。
バージョンを重ねて、便利なタグが増え、柔軟なテンプレートを組めるようになったのはいいのですが、 3系の頃から仕様が変わっていないので、ブラックボックスが多かったりと少し困ります。
Web上のドキュメントだけでは情報が不足している事が多いので、参考書等があった方がよいのかも知れません。
公式ドキュメントによると、MTArchiveNextは次のアーカイブ、MTArchivePreviousは前のアーカイブという説明なのですが、 「次」というのは「次のループにあるアーカイブ」なのか「次に新しく作られたアーカイブ」なのかで意味が違ってきます。
例えば、月別アーカイブが2009年の1月〜12月まであったとすると、以下のテンプレートタグで全て表示出来ます。
<mt:ArchiveList archive_type="Monthly">
<$mt:ArchiveTitle$><br />
</mt:ArchiveList>
デフォルトは降順で表示されるので、以下のような結果になります。
2009年12月 2009年11月 2009年10月 2009年9月 2009年8月 2009年7月 2009年6月 2009年5月 2009年4月 2009年3月 2009年2月 2009年1月
この結果から「2009年8月」の時は、「MTArchiveNext」=「2009年7月」、 「MTArchivePrevious」=「2009年7月」と思いがちだったのですが、実は違いました。
以下のコードを実行すると、よく結果が分かります。
<mt:ArchiveList archive_type="Monthly">
prev:<MTArchivePrevious><$mt:ArchiveTitle$></MTArchivePrevious>
| current:<$mt:ArchiveTitle$>
| next:<MTArchiveNext><$mt:ArchiveTitle$></MTArchiveNext>
<br />
</mt:ArchiveList>
prev:2009年11月 | current:2009年12月 | next: prev:2009年10月 | current:2009年11月 | next:2009年12月 prev:2009年9月 | current:2009年10月 | next:2009年11月 prev:2009年8月 | current:2009年9月 | next:2009年10月 prev:2009年7月 | current:2009年8月 | next:2009年9月 prev:2009年6月 | current:2009年7月 | next:2009年8月 prev:2009年5月 | current:2009年6月 | next:2009年7月 prev:2009年4月 | current:2009年5月 | next:2009年6月 prev:2009年3月 | current:2009年4月 | next:2009年5月 prev:2009年2月 | current:2009年3月 | next:2009年3月 prev:2009年1月 | current:2009年2月 | next:2009年3月 | current:2009年1月 | next:2009年2月
結果を見ると、ループの順番に関係なく、今のアーカイブを基準に次に新しいアーカイブがMTArchiveNext 次に古いアーカイブがMTArchivePreviousとなるようです。
なので、「次のループにあるアーカイブ」ではなく「次に新しく作られたアーカイブ」で、 ソート順は関係ないようです。
ここまで書いて気付いたのですが、MTArchiveNextはループ外でも使えるみたいなので、当然の挙動ですね。
調べていませんが、他のNext系、Previous系も同じ挙動だと思います。
サーバー環境にもよると思うのですが、テンプレート編集の際に、何らかのキャッシュが効いていて、 確認画面で見えるものと、実際に作られているプレビュー用HTMLファイルが違うというケースがありました。
テンプレートを編集して、「確認画面」を見ると、編集が反映されていない。 サーバーに保存されている.htmlファイルを見ると、編集が反映されている。
どういう事か調べてみると、出力ファイル名やテンプレート名を変えた後にプレビューで確認すると、 プレビュー用に読み込まれているiframeのファイルが変更前のプレビューファイルを参照していました。
ブラウザのキャッシュかとも思いましたが、どうも違うようで、恐らくDBのキャッシュが効いているのだと思います。 深追いはしていないので、MTが作っているキャッシュなのか、DBが持っているキャッシュなのか、 MTの不具合か、サーバー環境の問題かまでは分からないのですが、 おかしいと思った時は、サーバーに保存されているプレビュー用のhtmlファイルを直接見た方が良いと思います。 （付け加えておくと、現在は直っています）
MT4.2からはプラグインなしで、mtevalモディファイアを使う事で実現出来ます。
<MTEntryBody mteval="1">
上記のように書くと、エントリ本文でMTのタグが使えるようになります。
エントリ毎に個別のJSファイルやCSSファイルを読み込む時に、便利に使えました。
以下を参考に入れました。
あと、今回は入れていないですが、メールフォームやアンケートに使えるA-Formはおすすめです。
A-Form：MovableTypeにフォーム設置できるMTプラグイン｜Web制作のアークウェブ
flickrの写真表示には、ActionStremasプラグインを使いました。
MT4.25ではデフォルトで入っているみたいですが、今回インストールしたのは4.24だった事と、 作業時には4.25が出ていなかった為、Movable TypeのUSサイトから落としてインストールしました。
Action Stremasのバージョンは1.0です。
バージョンが2.0なら改善されているのかも知れませんが、1.0ではflickrの画像URLは一種類しか取得出来なかった為、 正規表現で置き換えました。
<mt:ActionStreams display_name="37to" lastn="20">
<mt:if name="__first__">
<div class="photos">
</mt:if>
<mt:setvarblock name="thumb_url"><mt:StreamActionThumbnailURL></mt:setvarblock>
<mt:if name="thumb_url">
<a href="<$mt:StreamActionURL$>"><img src='<mt:var name="thumb_url" regex_replace="/_t\./","_s\.">' /></a>
</mt:if>
<mt:if name="__last__">
</div>
</mt:if>
</mt:ActionStreams>
いい機会なので、feedburnerのフィードを独自ドメインで利用出来るようにしました。
DNSの設定でフィード用のドメインにCNAMEの指定を行うだけです。
前のURLはそのまま使えるので、以前からフィードを取得して頂いている方に影響はありませんが、 登録し直してもらえると助かります。
前から気になっていたのですが、フィードリーダーでフィードを読んでいると、時々過去のエントリがあがってきます。
何らかの修正が入ったので、更新されたのだと思いますが、フィードを見ているだけでは分からないので、 以下3つの情報をフィードに加えました。
日時だけで具体的な情報が入っていませんが、いくらかはマシだと思います。
最後に、デザインチェックも兼ねて、過去のエントリを見ながら、タグ付けをしていました。
文章も誤字・脱字や、気になった部分は少し修正したりもしたのですが、昔に書いた記事を読むのは色んな意味で恥ずかしいです。 子供の頃に書いた夏休みの日記を、大人になって読み返す気分でした。
マイペースですが、ブログを書き続けて良かったと思います。 これからも宜しくお願いします。
Posted at 37to : commetns(0) : trackbacks(0)
本エントリへのトラックバックURL
http://blog.37to.net/mt/mt-tb.cgi/118
