REDLINE MAGAZINE | カラム落ちとか自分のコーディングとかの話

カラム落ちとか自分のコーディングとかの話

先日の自分もプロパティの書き順とかのエントリに頂いたブクマコメントでこういうのがありました。forestkさん、コメントありがとー。

padding, margin が width, height の側に無いと調整してたら 「カラム落ちした！どこ？どこのサイズがでかいん！？」 とかならないですか？

結論から言うとならないようにしてます。というか、後からwidthをいじる必要がないように計算機使いながらやってます。探さなくていいように紙も使ってます。

せっかくなのでその辺り含めて、カラム落ちやコーディング手順について書いてみようかなと思いました。（前にもちょっと書いた記憶があるけど）

ボックスについて

カラム落ちって外枠のボックス自体に問題がある場合と中身に問題がある場合の2パターンあると思うんですが、まずボックス自体について。

頭の中の前提

2段組にしても3段組にしても、まずデザインの絵の中でそのボックス達が親ボックスの幅に納まってる限り、中の各ボックスの幅もそこに書いてある幅の通りで入るはずなので一旦指定したソース内のwidthはあまり気にならないです。（但し、「キツキツで余白がまったくない＞＜」って場合は若干慎重になるけれども。）

紙使ってます

気にならないというか、私CSS書くときに１度大枠のサイズを測ったら2度同じ部分の幅をFireworks等で確認するのが面倒なので大枠の幅に関しては適当な紙にフレーム手書きで書いてサイズ測ったときにそこにメモってます。カッチリした仕様書やコーディング用のルールなんかがまとめてある案件では元々ワイヤーフレームに値が書いてある紙をもらうことも。

例えば左右に分かれたデザインなら最初に左右のボックス幅を測る→紙に四角を並べて書いてそれぞれの幅メモ→その紙を見ながらCSS側で中身の細かい部分を書く前に先にfloatとwidthの指定だけ済ませておくという感じ。この時はまだ余白の類は書きません。後からwidthを確認する必要が出てきたらソースの前にその紙で確認して済ます事がほとんどです。（※もちろんそこに書いた値が間違ってる or CSSソースのwidth書き間違えてるなんて場合はアウトですが）

カラム落ち原因を探る時にwidthを気にしなくていいように

私はCSSを書く前にhtmlソースをすべて書いておく派なので、　上の時点で余白部分はおかしいけど、左右に振りたいボックスは分かれてる状態。そうすると本来clearされるべき箇所の位置がおかしいはずなので、それらのfloatをclearする要素に対して先にclear:bothだけ指定しておきます。そこで初めて一旦じっくりブラウザプレビュー。

中身はプレーンな状態ですが、左寄せの部分、右寄せの部分、clearされた部分の大枠のレイアウトはできてますよね。で、この時点でカラムが落ちてない限り、大枠のボックスのwidthが関係して落ちる可能性は原則としてないと判断してます。とりあえず原因の選択肢から消しておくという感じ。

そういう意味で、ボックスのwidthは基本的にデザイン変更がない限りは書換えしないのでプロパティのwidthと余白類の書き順が離れてても気にならないという訳です。

計算機を使ってます

逆に言うと落ちるのはmarginやpadding、borderがおかしいと私は考えてるわけですが、marginはともかく、たまにpaddingを入れる時のwidthの引き算を間違う事はありました（汗）なのでコーディング中、電卓は常に手元にあります。「電卓 > 自分の暗算力」です。アホなので。

CSSにpaddingを指定する時はまずpaddingを考えずにwidthを指定しておいて、最後に余白類を書くときにまずpaddingを書く→左右のパディングをwidthから計算機を使って引算→widthを書き直すという手順にしてます。頭の中で先に済ませてwidthを指定してもいいんですが、経験上、計算間違いが多いので＞＜

なんかね、「78 - 2(左padding) - 2(右padding)」とか簡単な暗算ならいいんですが、「53 - 7 - 7」とか遅いです。超文系なんだもん！

余談

今、widthって探しにくいんかな・・・と自分のCSSソースをいろいろ見てたんですが、なぜかwidthだけはパっと目に付きます。「w」が他の頭文字に比べて高さが半分くらいしかないからなのか、値が数字だからなのか、自分ルールが板についててココにあるって脳みそが判断してるからなのか、理由は定かではないですが、なんか見つけにくーーーーとはならなかったです。まぁ単にそんなに長々とした規則集合を書いてないからってことなのかもしれません。

CSSを始めた頃は1つ規則集合を書くたびにブラウザでプレビューを繰り返してた慎重派だったんですが、最近はhtmlソースと絵を見ながら脳内でCSS置換してキリのいいところまで一気に書いてから細かくプレビュー確認してます。なので、同じボックスの部分を一気に書いてるのに1つだけwidthがおかしかったら「あれ？」ってその時点で気づく可能性も高いです。

Firefoxを指定間隔で再読み込み

プレビューで思い出した。以前hamashunさんのブログでAutoHotkeyを利用してブラウザのリロードをエディタから行って効率を上げるという話を拝見したんですが、（AutoHotkeyでHTML&CSSコーディングの速度を上げる | Blog hamashun.com）自分には高度な事のように思えたので私はFirefoxのアドオンを利用してブラウザのリロードを自動的に行いながらのコーディングをしてます。

FirefoxのアドオンのTab Mix Plusに「指定間隔ごとに再読み込み」という機能があります。コーディングする際、一方のモニタにエディタ、もう一方にブラウザを開いて作業してるんですが、この「指定間隔ごとに再読み込み」を1分とか2分にして（秒単位でも指定できるんですが、そんな頻繁にされてもウザいので）勝手にリロードしてもらってます。CSS書きに没頭してても内容が自動的に最新のものに書き換わってくれてるのでスゲー楽です。オススメ。

で、これを使ってるとエディタに没頭してても自動リロードの際に自分の視野内で一瞬ブラウザがチカっとするんですね。そしたら「あー今リロードしたな」っていう気配を感じるので一瞬だけチラ見するんですが、カラム落ちしてたらそのチラ見できっと気づきますよね。そしたらそのリロード前の1分なり2分なりの間に書いた部分のどこかに問題あるわけで、そこだけ見ればいい、と。1.2分で書けるソースの量はたかだか知れてるので問題箇所を見つけるのは安易かと思います。もちろんカラム落ちに限らずチラ見で気づくくらい大きなミスはこれで早めに気づくことが出来ます。

IE6には先手必勝で戦いを臨むようにしてる

よく考えたら、カラム落ちって多分コレIE6の話なのかな。違うかな。他ブラウザでカラム落ちるのって幅の勘違いじゃなかったら多くの場合はimgで入れる画像の幅勘違いしちゃった時くらいじゃないかなと思うのだけれども。

floatしてる部分にmarginを指定する時は必ずdisplay:inlineをIE6用に入れてます。これ入れとけばIE6でfloatしたボックスがmarginを倍とる現象から防御できるので、とりえあずこれで先手を打ってます。floatしたボックスはdisplayの値が何であろうと関係ないので他ブラウザに悪さする事もない。文法的にも問題ない。

>>IE6で落ちるサンプル
>>IE6でも落とさないサンプル(display:inline付)

ボックス内に問題がある場合

もしカラム落ちしてボックス自体に問題ない場合は中身を拾っていきます。CSSソースを直接確認するよりも、FirefoxならFirebug、IEならDebugBarを使って画面をなぞって調べた方が楽なので今はそうしてます。

FirebugならHTMLの問題箇所の要素名のところを順番にマウスでなぞっていってボックスのwidth、margin、paddingが色分けされるので「あーはいはい。これね。」って多分すぐに分かります。DebugBarの方は色分けはできないんですが、何かターゲット（的の絵なのかな）っぽいアイコンをグイーンってドラッグして該当箇所あたりをなぞると枠線が出るのでその中で意図しない幅に拡張してる犯人を捜します。

以前CSSで全称セレクタを使ってborderを指定して（入れ子になってる部分は線色変えたりして）確認した事もあったんですが、面倒なのでやめました･･･。

犯人見つけたらその部分のソースを書換え。Firebugだったら、もうそのままFirebugの中で値書き換えてコレでオッケ－！って確認してから本ソース書き換えてます。リアルタイムに内容が反映されるのはホントに助かってます。

それでも犯人が見つからなかったら･･･htmlソース少しずつコメント化するか消すかして、どの要素が問題か突き止める、かな。（最近そこまで強力な敵に出会った事ないけれども多分そうすると思う。）

とりあえずカラム落ちしたらまずはコレ確認

• 閉じタグ忘れ等、文法エラーはないか
• 該当ボックス内でCSSでブロック要素に親ボックスよりデカい幅を指定していないか（IE6）
• imgで入れてる画像の幅がボックス幅を超えてないか（pの中にimg入れてたりする場合、そのpの余白の部分を計算に入れずに画像書き出してないか）
• margin、paddingの計算間違ってないか

2つ目の「該当ボックス内でCSSでブロック要素に親ボックスよりデカい幅を指定していないか（IE6）」なんですが、自分の経験ではコレ、原因の特定が遅くなることも多かった気がします。サンプルはこんな感じです。

>>IE6で落ちるサンプル

floatしてるボックスでもwidthが200pxのボックスにそれ以上の幅を指定した要素が入ってるとIE6では落ちます。これに関してだけはIE6が悪いんじゃなくて間違った幅指定してる書いた本人も悪いと私は思うんですが、結果として落ちるので注意、と。上のサンプルの中のh2部分のような箇所で幅指定してなかったらは基本的に幅は親ボックス幅になるからいいんですが、以前このパターンで油断して幅入れてなかったら遠い遠いところの幅を継承しててIE6で落ちてた事もあった気がします。

長くなってしまったけど、自分はこんな感じでコーディングしてます。

2009年03月01日 16:03 | Red | パーマリンク