サンプルHTMLの表示に於いて、
IE8、Firefox3、Safari3(chromeも)では、

この画像のように、ボックス間に隙間が空いてしまいます。
IE6,7、Opera9ではボックスAとボックスBは密接します。
ボックスAは、marginもpaddingも(borderも)なし。
Aの子ボックスのbottomにmarginが入っています。
名だたるモダンブラウザがほぼ全滅
本来?なら、ボックスAとBの隙間はボックスAの背景色で埋められるのが直感的なレンダリングです。
ところが、モダンブラウザと名高いIE8、gecko、webkitがボックスAの背景をキャンセルしてしまいます。
うーむ。ここまで、そろいもそろってですと、流石にバグではなく仕様なんでしょうね(´・ω・`)
親ボックスのpaddingにダミー値をいれて対策
良くある実例では、ボックスAが id=”main” ボックスBは id=”footer” で共にダミー的コンテナボックスだったりで、余白系の値は0にされていることでしょう。
大抵の場合は無調整で問題ないのですが、
(無駄に)複雑な多重背景で、うかつなズレが許されない場合がままあります。
そんな際の、margin、padding、時にはborderで、ごまかす調整するでは、キャンセルされるボックスAのbottomにpaddingの値を与えてやるのが良さそうです。
「固定幅+中央寄せ」時の背景ズレ対策を半年以上前に書きました。
背景画像がブラウザをリサイズすると1pxうねりますよね?
その補整に関する記録です。その際は、偶数幅のものをセンタリングするからうねるのだと思っていたのですが、よくよく考えてみると、奇数でもうねるんですよね。他にも色々と気になり、もう少し突っ込んで検証してみました。
検証用素材HTMLをご覧ください。
奇数幅でもうねります
センタリングでは、
ブラウザ幅が偶数幅の時は奇数幅画像がずれ、
ブラウザ幅が奇数幅の時は偶数幅画像がずれます。
1px違いますので当然です(ノ∀`)
ずれ方が違う……
msieもgeckoもoperaもwebkitも……リサイズで黒と赤の線がチラチラしますね(・ω・)
よくよく考えてみました。
余ったマージンを左へ送る場合

ブラウザ幅が偶数の時に右に黒線が出ます。
余ったマージンを右へ送る場合

ブラウザ幅が偶数の時に左に黒線が出ます。
つまり、ブラウザ幅が偶数の時と奇数時で、余分マージンを送る側を変えるレンダリングエンジン以外は、リサイズで黒と赤の線がちらつくことになります。
幸か不幸か、現状のメジャーなレンダリングエンジンは全てちらつきます。
各ブラウザの特徴
IE6,7だけ(6未満は無視)が左に余分マージンを送るようです。他は皆右へ。
IE6.7以外は、偶数と奇数の画像を混在させない限り、ずれな……ん?
いや、それって偶数と奇数がずれるのであって、バックグラウンドとフォアグラウンドがずれる原理とは関係ありませんよね\(^o^)/
フォアグラウンドのずれ方を見る
ブラウザ幅に限らず線と画像が合う、operaとwebkitは、問題ありません。
これらは、偶数と奇数の画像を混在させない限りずれないと言うことです。
問題は、msie6,7とgecko。
マージン送り方向という考え方では、どうも、バックグラウンドとフォアグラウンドで逆にマージンを送っているようです。
msie(6,7)
バック 余分マージン左送り
フォア 余分マージン右送り
gecko
バック 余分マージン右送り
フォア 余分マージン左送り
msie8,opera,webkit
バック 余分マージン右送り
フォア 余分マージン右送り
対策
結局、前と大差ありませんorz
- IE6.7は背景画像の右端に1ピクセル足す
- FireFoxは背景画像の左端に1ピクセル足す
- 奇数幅でそろえても無駄\(^o^)/
動的にjQueryで内幅を変えるのも面白いかなと考えていたのですが、
ブラウザ間の「ずれ方」の差異は幅いじりだけでは無理のようです。
具体的に
標準モード
#main {
background:url(main-bg.gif) repeat-y center 0;
_background:url(main-bgie.gif) repeat-y center 0;/* IE6 センタリング補正 */
*background:url(main-bgie.gif) repeat-y center 0;/* IE7 センタリング補正 */
}
#maincontainer:-moz-read-only {
background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}
互換モード
#main {
background:url(main-bg.gif) repeat-y center 0;
_background:url(main-bgie.gif) repeat-y center 0;/* IE6,7 センタリング補正 */
}
#maincontainer:-moz-read-only {
background:url(main-bgff.gif) repeat-y center 0;/* Mozilla センタリング補正 */
}
で動くっぽいです。
どうもIE8がくせ者です。
互換モードでは新セレクタが機能しない((((;゚Д゚))))
互換モード時にはヘッダに、
を追加したら上手くいきました。
アンダースコアハックやらスターハックが無効化されるようです。
単純なリキッドレイアウトは画面が狭かった時代の遺物だと思っています。
もちろん、リキッドを全否定する意味ではございません。
アマゾン風リキッドを知る
jQueryで作るAmazon流リキッドレイアウトを読んで、始めて最近のアマゾンのリキッドレイアウトを知りました(ノ∀`) ブラウザの横幅に応じて、表示点数を変える(ずらすのではなく)レイアウト。
なるほど。これはある。あるぞぉーーー
記事はどうやら、jQueryを使うことに主眼があるようで、jQueryを使わない実装には触れられていませんでした。
とりあえず作ってみる
さらっと作れるじゃんね。一応プロだし(ノ∀`)
ん。。。むむ……案外手強いwwww
アマゾンどうのこうのの部分は問題ないのですが、それ以前のリキッドレイアウトが手強いぞーー
というか、リキッドの案件なんてほとんど縁が無かったな俺(・ω・)ダメじゃん
練習じゃぁ!
危機感を感じ、とりあえず練習に。
目指すは、本文部のみがリキッドの3カラムレイアウト。
- IE6でウィンドウ幅を縮めると左サイドが散歩に出かける
- ウィンドウリサイズ時等々、挙動がおかしい((((;゚Д゚))))(IE,Opera)
なんじゃこりゃ。・゚・(ノ∀`)・゚・。
IE6がどうのこうの以前にIE7でどうにもならん((((;゚Д゚))))
ふぅおちつけ。良くある事じゃないか。
どうせ、ブロックモデルの解釈がおかしいに違いないさ……
なーんだ、あっさり動いたじゃん……IE6のアレ以外は。

ちょっとネガティブマージンから離れてみましょうか……
お!IE6でも大丈夫じゃん!
って、フッタを突き抜けてます。当然です。それがアブソリュートです。
本文部と、サイド部を別レイヤーにして、サイド部を丸ごとアブソリュート。
フッタを突き抜けないように、JavaScriptで高さをリアルタイムで調整(゚Д゚)食らえっ!
やけくそだったのに、リサイズ時の値取得が上手くいかず放心。
まて、リアルタイムにサイズを変えるなら、リキッド部の横幅を弄ればいいじゃないか……
もうね、素直にリキッド部の幅をJSで弄っちゃいますよ。ええ。
ええ、普通に動きます。柔軟性も結構ありますよ。ええ。
なのになんでしょう。この敗北感は(´-`)
そうだ!jQueryで作るAmazon流リキッドレイアウトを読んで、いやCSSでいいじゃん?と思ったのが発端だったのです。
まぁ、該当箇所こそあっさりCSSで動いてますが、ソレより基本とも言える部分でjQueryを必須にしてしまう訳には参りません。
挙動のおかしなIE6だけをJavaScriptでねじ伏せれば良いのです(゚Д゚)
世に出回ってるサンプルも結構眺めました。
上手く動いている物は、大抵、サイドも可変となるパーセンテイジ指定でして、本文部のみリキッドというタイプは、どれも、IE6のこの挙動に関しては放置しているようでした。
テーブルよりはJSかな(´・ω・`)IE6(正確には7未満)だけに適用もできるし。
と言う訳で、今回の修行はここまで(゚Д゚)今日のところは勘弁したらぁ
女子美術大学みたいなことできる?と聞かれサンプルを製作。
実は、その昔に挑戦してクロスブラウザの面で失敗したことがあり(ノ∀`)
いやぁ、jQueryは便利ですね(・ω・)表示すべき「幅」の取得も楽にできてしまいました……
スクロールバーの幅とかは考えずに、windth:100% のブロック要素の幅を取るのが吉なのかもしれません。
CSSだけで動くのはIE位でしたが、背景ストレッチくらいは標準機能であっても良さそうなものです。
追記
flash背景のが軽いっぽい(・ω・) flash背景サンプル
ランダム背景やら伸縮の微妙な具合やらも調整の幅が広そうだし、縦幅を固定しようとすると、jQuery+私の技術では厳しかった(ノ∀`)overflow:hiddenも効かず。
なにより、flashのが軽い((((;゚Д゚))))
Safari3とFirefox3で文字間が違う
「Macのフォントは文字間が広い」という認識で居たのですが、近頃のMacのFirefoxはそうでもないのですね。
というか、Firefox3とSafari3で同じプロポーショナルフォントを指定しても文字間が違ったのでびっくり。
根拠の薄い直感では、Firefoxが文字間をWindows的に縮めている感覚。
普段は余裕を持たせてコーディング
大抵のデザインでは、テキスト文字(なんたる表現^^;)のドット的長さに余裕を持たせており、文字量が多少前後してもレイアウトに大きな影響を与えない事が前提とされています。そしてHTML化も、そのポリシーに従う日常です。
調整が必要なケースも
Mac Safari3だけデフォルトでの文章改行位置が酷く格好悪くなってしまうケース。そこだけ画像で処理する訳にもいかず。
今回遭遇したそんなケースでは、素直に文字間を弄りました(ノ∀`)
MacのSafariだけletter-spacing:-1px;
ドット的には -2px くらいがちょうど良さげでしたが、将来Mac Webkitの挙動が変わった際に文字が重なってしまう可能性を考えると、最小限の調整で済ませたく感じ1pxに。
互換モードじゃありませんか
DOCTYPE宣言によってはIEの挙動がバグだらけになります。
いわゆる「互換モードと標準モード」における、互換モードの問題です。
そうならない様に「標準モード」になるDOCTYPE宣言を使用するのがセオリーなのですが、今日行ったコーディングではレギュレーションで互換モードが指定されており、久々に汗をかく事に。
ズームでずれる
IEの互換モードではblockのmarginがマトモに解釈されません。一見上手くいっていても、ズームしてみるとずれたり(zoom:1;でも無理)。
私の場合、これはpaddingを主に書き換え必要ならばblockを入れ子にして対応します。
まぁ、ここまでは、HTMLコーディングではよくある事です(ノ∀`)
印刷でずれる
position を使用していると、何故か印刷でずれまくります(ノ∀`) もちろんIE互換モード。
小一時間悩みました。どうやら、印刷の場合はpaddingがマトモに解釈されないようです。
つまり
IE互換モードの(特にpositionを使う)場合、
- ブラウザ上では特にズーム時にmarginの解釈がおかしい
- 印刷上では特にpaddingの解釈がおかしい
状態になってしまいます。
今回は、IEのみに印刷用CSSを当てる事で対応しました。
画像のサイズが合わない
あれ、この画像のサイズ、ナンボだっけ?等と、右クリックしてしまう事はコーダの日常茶飯事ですが、どうも最近、そのサイズがおかしい(・ω・)実値と違う事があるのです。

IEではpaddingを含む
どうやら、IE7(IE6もだった)では、imgのpaddingを含んだ値が表示される模様。
たとえば下記のように。


それぞれ、同じ画像ファイルですが、IE7にて「右クリック→プロパティ」で確認できる画像サイズは異なります。
また一つ横着出来なくなりました(ノ∀`)
はてブがリニューアル
気になる本を見つけたら、はてブにブックマークする癖が付いてしまいました。
雑多なブックマークからアマゾンを抽出し、ブログの端にリストしていたのですが、はてブのリニューアルに伴い使用不能に(ノД`)
自分のブックマークから「抽出」して「フィード」を得る機能がごっそり無くなっており、微妙に不便に。
Yahoo!pipesでごにょごにょ
フィードの加工でしか使った事がなかったのですが、どうやらHTMLをこね回してフィード化する事も出来る様子。
Yahoo! Pipes で、RSS を出力してないサイトをRSS化する – Fetch Page モジュールなどを参考に、とりあえずやっつけてみました。。
RSSを理解していないので、フィードとして正しいかどうかさえ分かりません(ノ∀`)挙動もちょっと怪しいです。
とりあえず、用は足しているので今日のところは撤退。
———
2008年12月12日追記
はてブコレクションのRSSが機能するようになっていたため、それを加工する方法に変更。