CSS HappyLife ZERO が移転したのでお手数ですが、消えちゃう前にブックマーク等変更してもらえるととても嬉しいです。
制作会社でコーディングする場合、社内のガイドライン的なのが有ったりデザイナーもある程度固定されてると思うので、毎回似たような事を確認したりとか、このデザインはどういう意図なんだろう？ってのも、何度か同じ人とやってれば見えてくる訳ですが、フリーランスの場合だとデザイナーは毎回違っていたり、当然ディレクションをする人も違うので最初に確認しておきたい事が有ったりします。
って事で、その辺りをまとめてみたり、デザインを渡されたときにこのデザインの意図は？って思う事とかもばーっと書いてみます。はい。
なので、デザイナーさんもコーダーにデザインを渡すときに気をつけて欲しい点とかもわかってしまうすばらしい内容（だと良いな）！
]]>
じゃあまずは最初に確認しておきたい基本的なことから行ってみようかと思うです。
この辺はディレクターさんに確認する事が多い部分ですね。
基本的な確認事項
どっかのモバイルエントリーと構成が似ているような気がしないでもないけど気にせず、これらを少し具体的に。
DTDは？
今だと大半が「XHTML 1.0 Transitional」ですが、もしかしたらHTML5が使えるかもしれないし、HTML4.01だったりするかもしれません。
他に、XHTML 1.0 Strict だったりでしょうか。案件ベースで Strict はあんまり見ないような気もしますが。
文字コードはutf-8でOK？
感覚的には8割以上が utf-8 ですが、時々 Shift_JIS だったりしますね。
EUCはここ数年言われた事無いかな。
keywordsは？
こちらで決めるケースは殆ど無かったんですが、お任せな場合は最低限のルールを確認しておきたいですね。
とはいえ、多くの場合サイトマップと一緒に指定されてたりします。
descriptionは？
個人的には入れない方が良いと思ってますが、基本的にはkeywordsと同じですね。
titleの記載ルールは？
指定があるかどうかの確認。
リニューアルなら、現状の記載ルールがイケてない場合ルールを変えても良いか。
ディレクトリのルールは？
画像やCSS、JSファイルは何処に置くのかとかそういうのの確認です。
この辺りは結構ルールが違ってたり、厳密に決められてる事も有るので要確認です。
ファイル名は？
各ページのファイル名は、こっちが決めていいのか決まっているかの確認です。
多くの場合サイトマップと共にちゃんと決められてるケースが多いですが、明らかに翻訳ミスだったり書き換え忘れなんかもボチボチ見受けれれるのでそういう場合は気づいたときに確認するしか無いですね。
対応ブラウザは？
この連絡が無かったケースは無い気がしますが、対応ブラウザの指定が古い場合も有ります。
IE6はまだ入ってて当たり前って思えますが、地味にFirefox 2.x が指定されている事もあるので最新でOKか確認したい部分ですね。あと、Safari3とか。
ちなみに、Operaが記載されていたのは見たこと無いかも。一応ボクが組むときは見ては居ますが。
IE6は何処まで厳密に対応すべき？
今後この確認が増える気がします。代表的な部分なら角丸のIE対応は必須ですか？とか。
未対応でOKはまだ少ないかもしれませんが、最低限レイアウトが崩れなければOKという事も有るかも知れません。
ヘッダーなどの共通パーツはどのように処理する？
SSIによるインクルードが使えるか、phpによるインクルードが可能かの確認。
どちらもダメで、JS使ってインクルードする事もあったり。この方法はお察しの通りなので、リスクを承知のうえでやるかどうかですね。
全部使えない場合は、メンテナンス性は落ちるけど仕方ないっすね。そういう場合DW頼りとかになるかな。
あ、後はMTとか使うならモジュールテンプレートとかで管理するケースも有りますね。
拡張子は、htmlが必須？
上記の条件によって変わる場合も有りますが、拡張子はhtmlが良いと言われる事は多いような気がします。
その場合、.htaccessがちゃんと使えるかどうかも確認ですね。
サーバによっては、SSIは.shtml でしか許可しませんとかあったりするのでその辺りは要確認です。
システムが入る場合、留意点は？
CMSも色々有りますし、大規模サイトだと複雑なシステムが入ってたりってケースもあるので、そういう感じの場合何処に気を付ければいいかわかってると出戻りが減って良いかなと。
アクセス解析は何が入る？
後から専用のタグを全ページに設置すると、結構な手間になるので予め確認しておきたい部分です。
javascriptは自由に使える？
これも導入されてるシステムに依存する場合があったり、何かルールがあったりするんで確認しておきたい部分の一つ。
後から、jQueryは使わないで欲しいとか言われるとアレですからね。
その他注意事項等は？
色々上げてきましたが他に、SEOがどうなのでこうして下さいとか、ロールオーバーはこうするとかが決まってる場合も有ります。
後から見出しのレベルを一段階変えて欲しいとか、ソースコードの順番をこうして欲しいとかもあったりして大変なことにならないようにしたいですね。
あと、印刷対応なども確認しておきたい部分です。
ざっと、基本的な部分はこんな感じでしょうか。
ここまででも1エントリー分くらい書いた気がしないでもないですが、本題はここから。
デザインに関して確認しておきたいこと
デザイナーさんとの関係が築けてればツーカーな部分も有りますけど、デザインを見ただけだと、「どーしたら良いんだコレは？」とか「こだわり？それともただのミス？」などあったりするんでその辺りに関して。
PCの場合だとどんなデザインでも、その一枚絵を再現するだけなら十中八九可能です。
だけど、実際にはテキスト量が変わったり文字サイズが変わったりしますし、実現は出来るけど工数が増える割に意味があるのかどうかわかんないデザインだったりってケースも有るわけですね。
なのでどの辺に気を付けてもらえるとコーダーは助かるのかが分かることで、きゃっきゃうふふな感じで連携が取れるかも知れません！
faviconは有りますか？
faviconが予め用意されているケースが案外少ないので、お願いするケースが多いんですが、この辺りは用意しておいてもらえると助かる感じです。
リンクカラーの指定は？
コレも案外無かったりして、visitedは？hoverは？activeは？などと聞くことが有るのでデザイン上どこかで分かるようにしてもらえるか予め指示が有ると嬉しい感じです。
デバイス？画像テキスト？
デバイスかどうかは、アンチの有無で判断するのが大半ですが、稀に全部アンチが掛かってたりして分かりにくい場合があるのでそういう場合は、何処がデバイスかを分かりやすくしておいてもらうなり指示を出してもらうなりが有ると嬉しい感じです。
複数行になった場合の処理
今のテキストが2行や複数行になった場合どのような処理をすればいいか分かるようになってるととても助かります。
ワイヤーフレームが2行になってないと、2行になってる状態のデザインを入れにくかったりもするかもなので、ワイヤーフレームの段階から2行を想定している感じだと良いのかなと。
背景画像の切れた先の処理は？
例えば全体にでかい一枚絵があったりする場合に、デザインデータの横幅が1200pxで1400pxになった時に元の画像が1200pxで切れちゃってると後で用意してもらわないといけないので予め横幅極端に大きい場合の処理などをしておいてもらえると助かります。
他に各ページのページタイトルとかで一枚絵っぽい背景画像を使う場合も、テキストが2行になったりした場合用に見えない部分もカットせずに残しておいてもらえると嬉しい感じです。
このリストのマーカーは標準？画像？
普通にリストスタイルを指定すると「disc」「circle」「square」のドレかになるわけですが、限りなくdiscっぽかったりする場合とか、こだわってdiscっぽくしてるのかdiscで良いんだけどデザイン上では厳密に作ってないだけかが判断付きにくかったり、用意されているマーカーの場合、マーカーとテキスト間の余白は変更できないので、標準でOKな場合その辺りの余白も合わせておいてもらえると分かりやすくなって嬉しい感じです。
微妙にマーカー画像のサイズや色が変わった？
あるページでは 8x8 の画像が別のページだと 10x10 になってたり、目視では殆どわからない程度にカラーが変わっていたり。
多くの場合これらは意図していることが多いと感じてますが、それってデザインした本人とコーダー以外が気づくのかどうか。自己満足になっていないか。仮にユーザーが気づいたとして、それによってサイトの印象が良くなるのかどうか。
その辺りのバランスだと思うんですよね。デザインパターンが増える場合、コーダーは確実に工数が増えるので、気づかれないような変化にまでこだわり過ぎるのも行き過ぎな感じが有るかなーと。
順序リストの数字だけ太字だったり色が違う
これは結構知らずにってパターンが多い気がしますが、順序リストの数字部分（グリフでもそうですが）だけ太字にしたり色を変えたりするのは地味に困る部分。
ブラウザ依存のマーカーの場合、テキストと同じ指定が反映されるので太さや色を変えるとなるとマークアップが以下のようになります。
<ol>
<li><span>テキスト</span></li>
<li><span>text</span></li>
<li><span>てきすと</span></li>
</ol>
こんな感じで、spanを追加して指定する必要があるわけですが、変更しない単発のページなら良いんですけど、ブログとかお客さん側で更新する場合や、やたらとリストが多い場合だと、毎回spanを突っ込むのが現実的じゃないケースも有るんですよね。なので、本当に数字は太字じゃないとイケないのかどうかを判断してからデザインに落としこんでもらえると嬉しい感じです。
逆N型の順番に並んだリスト
リストをインラインなりフロートなりで並べると、
1 2 3
4 5 6
7 8 9
って感じでZ型の順番になる訳です。
だけど、時々
1 4 7
2 5 8
3 6 9
って並んでいる場合があって、コレがデザインする時に単純に楽だからこう並んでいるのか、意図しているのかが判断付きにくかったりするんすよね。
コレは結構厄介で、今9個のが12個になった場合、後者の並び方だと単純に足すだけじゃダメで何かしらグルーピングするdivとかが必要になったりして、リストならul要素を閉じる必要も出ちゃうので一塊なハズが別のリストになってしまったりっていう問題が出てきます。
なので、デザインする上で手間でもZ型の順番で並べてもらえると嬉しい感じです。
・・・ぇ、columnプロパティ使ってOKだったの！？なら、何の問題もないです。
同じ（にしか見えない）サイズのボックスが並んでいる場合
同じサイズのボックスがポコポコ並んでいるのはインデックスページとかでよく見るヤツですが、どう計算しても1px合わない場合って有ると思います。
その時に、そのサイズが最後だけ違ってたり余白の取り方が最後だけ違うと結構キツイっす。
例えば、180px * 3 と思いきや、最後だけ 179px とかにして帳尻合わせしている場合や10pxでマージン確保してるのに最後だけ9pxで調整している場合です。
その並んでるボックスが絶対に変わらないなら良いんですけど、変わる可能性がある場合は、左右どちらかの端っこが1px足りない感じで合わせてもらえると嬉しい感じです。
行間がページによって変化する
「テキストばかりのページでここだけ重く感じるから」みたいな理由で、行間が他より大きかったりフォントサイズが変わっていたりっていうケース。
デザイナーの意図やこだわりはすごくわかるけど、そのルールの明確な切り分けは非常に難しいんですよね。
画面全体の何割がテキストだったらその行間になるのかってのが、そのデザイナーにしか判断出来ないとメンテナンス性は悪くなってしまうし、逆にそれに違和感を覚える人も居るだろうし。
ページ単体で見たら良いと思うけど、サイト全体で見るとやっぱりソコだけ浮いてる感じがする場合が多いんじゃないかなぁと。
隣のボックスと合わせて上下が中央揃い
2列なボックスがあって、左のボックスの見出しは2行になってて、右のボックスの見出しは1行だけど、左のボックスと高さを揃えて上下は中央にする。それが行毎に存在するような場合です。
フロートしたボックスの高さを揃えるのに heightLine.js とか使うケースが多い訳ですけど、その中の見出しも高さを揃えて、さらに左右のボックスで見出しの上下中央揃えまでくると鬼デザイン扱いの一つかと。
テーブルだったらセル内で上下中央は簡単だけど、CSSは高さが可変な要素に対して上下中央を取るのが結構厄介なんですよね。
特にボックスの数がページによって変わったり更新される場合、テーブルで組んじゃうとデザインを再現できてもメンテナンス性は悪くなってしまうので、上に揃えてもらえると嬉しい感じです。
確認事項と言うよりお願い的な
なんか色々書いてきましたけど、上に書いたことなんかよりも何よりも、pxズレが一番時間を取られてしまう部分だったりするので、ソコを一番気を使ってやってもらえると嬉しいです。
高さはズレてても全体のルールが分かってれば良いんですけど、横幅（縦のライン）がズレてると調整したりという作業が発生しちゃうんですよね。
コーダーにもよるかと思いますが、大抵の場合はコーダーが一部を削ったり増やしたり、ズラしたりして調整しているので、よく分からずコーダーが不機嫌にならないためにも（笑）気を使ってもらえると嬉しいなと思います。
ホントはもっともっと色々有るわけですが、書き出したらたぶんキリがないかなーと。
例えば、角丸 + グラデーション + ドロップシャドウ みたいなのも出来るだけヤメテ欲しいですが＞＜
コーダーもデザインを・・・
デザイナーはこうしてくれよー！みたいな事も結構書いた訳ですが、デザイナーのデザイン意図や目的、もしくは単純なミスなのかどうか。そう言うのの判断をするには少なからずコーダーもデザインを分かってないと出来ないと思うんですよね。
よく、「あのディレクターはあのデザイナーは、コーディングのことをわかってない癖に・・・」みたいな事を聞いたり、まぁ思ったりもしますが、その逆も然りでコーダーがデザインのこと分かってないのはよろしくない訳で、デザインが苦手だからとか嫌いだからでコーディングやってる人も、デザインに関して知ってた方が良い事はたくさん有るかなと。
そうすると、この人は9pxを狙ってんだな。とかこの人の9pxは10pxのミスなんだな。とかも分かってきますし！
コレが分かることによって、このデザイナーの場合はキッチリカッチリやらないとマズいな！とかこのデザイナーならズレてても大丈夫だから手を抜いてやれｒｙ・・・
・・・まぁそんな訳で、コーダーってやること多いですね。
(X)HTML + CSSは当たり前。でも主流なテクニックとかは日々変わっていく。HTML5？CSS3？JSも覚えなきゃ！モバイルも必要？iPhone対応？スマートフォン対応？iPad対応？サーバ関係もある程度分かってないと！winサーバやめて！SEOも知らないと困る！ユーザビリティって何？アクセシビリティって何？ ぇ、何かしらのCMSも使えないのお話にならない？phpも覚えろ？UX？IA？...さらにデザインも理解して無いとダメ？
おー、何かコーダーってスゴそうだ！
ということで、コーダー頑張ってます。（なんて素敵な終わり方！
]]>
'
});
$.uHat.openAll();
});
