この現象を再現してみよう。スタイルシートとHTMLは以下の通りである。

●Firefoxで表示させた場合 ●IE6.0で表示させた場合

これをFirefoxとIE6.0で表示させ、それぞれスクリーンショットをとってみた。二つのパラグラフは、font-family以外まったく同じスタイル指定なのだが、IE6.0では、1行目に「font-family: "細明朝体"」としたパラグラフへのスタイル指定がすべて無視されてしまう。（→テストページ1）

原因、というか、この現象が起こるメカニズムは解明できなかったのだが、検証した内容を簡単にまとめておく。

まず、悪さをしているのはおそらく「細」「明」「朝」「体」という4文字のうちのどれかではないかと当たりをつけ、個々の文字で試してみたところ、「細」と「体」でこの現象が起きることがわかった。

次に「細」と「体」の文字コードを調べてみると、前者は8DD7、後者は91CC。それぞれの末尾の文字コードが共通する「沌」（93D7）、「栂」（92CC）、半角カタカナの「ﾗ」（D7）、「ﾌ」（CC）でも試してみると、想像通り、いずれの場合もスタイル指定無視が発生した。

さらに、文字を囲むダブルクォーテーションをとると、以降のスタイル指定がすべて無視されるのでなく、その次の行だけ無視されることがわかった（→テストページ2）。

種明かしのようになってしまうが、実は、この現象はMovable TypeでWebサイト構築を行っているときにたまたま発生した。「Movable Typeで～」ということは、HTMLファイルの文字コードはデフォ ルトではUTF-8になる。それに対して、CSSファイルはDreamweaverで作ってFTPで直接サーバーにアップロードしたので、文字コードはシフトJIS。つまり、HTMLファイルとCSSファイルの文字コードが一致していないためにこのような現象が起きたのである。したがって、CSSとHTMLの文字コードを統一するか、または、CSSに文字コードを明示すればこの現象は回避される（→テストページ3）。

前回、触れたように、「display: inline-block」にはMac版IEでもfloatクリア効果がある。しかし、Win版IEと違って、「display: block」に戻すとfloatクリア効果も消えてしまうので、その部分にバックスラッシュハックを用い、適用対象からMac版IEを除外する。結局、最後にハックに手を出してしまい、スッキリしない気持ちは残るが、これで、晴れてMac版IEでもfloatをクリアできるようになったわけだ。

ただし、気を付けなければならないのは、このclearfixを適用させた要素は、Mac版IEではインライン的に扱われてしまうこと。例えば、margin: autoでのセンター合わせなどはできなくなる。したがって、div要素などに一律に指定するのでなく、上記ソースのようにクラスとして用意し、floatクリアが必要な要素にだけ適用させるようにしたほうがいい。でないと、Mac版IEで予期せぬ事態を引き起こす。

もし、インライン的に扱われることを嫌うなら、ソースとしてはますます汚くなるが、下記のように「overflow: hidden」をMac版IEにだけ適用させる方法もある。

2. 内容的に理にかなっていること、意味不明でないこと
いわゆるCSSハックは、記述通りに理解しようとするとその多くが意味不明である。文法的に間違っていれば当然として、仮に文法的に正しかったとしても、そういったテクニックにはなるべく頼らないようにしたい。また、CSSプロパティを本来とは異なる目的で使用することもできる限り避けたい。

3. シンプルであること
極力無駄な記述を省き、1行でも短くする。

さて、前置きが長くなってしまったが、本論に入ることにする。今回のIE編の検証にあたって用意したスタイルシートとHTMLは以下の通りである。（サンプルページはこちら）

簡単に解説を。

その1の「height: 1%」は、IE向け記述の標準形。通常は、IE以外に適用させないために、いわゆるスターハックと組み合わせて、「* html .clearfix { height: 1%; }」という形で用いられる。別名、Holly Hackとも呼ばれる。（IE Escaping Floats Bug 参照）

その2の「display: inline-block」は、一般にIE7およびMac版IE向けの記述とされるもの。すぐその後に、「display: block」としているのは、Opera、Safari対策である（inline-blockについては、inline-blockの奇妙な世界 参照）。

その3の「zoom: 1」は、IE5.5以降の独自拡張であるzoomプロパティを利用した記述で、Holly Hackと同じ効果をCSSハックに頼ることなく得られる。

その4とその5は、IEに限らず全ブラウザが対象で、いわゆるclearfixのようなややこしいことをしなくてももっと簡単にfloatをクリアできる、としてよく紹介されているテクニックである。（CSS - Clearing floats 参照）

さらに、モダンブラウザへの影響を調べるために、全ブラウザ向けのその4とその5を除いては、after擬似要素を用いたモダンブラウザ向けclearfixも併記した。

このソースを用いて、各ブラウザで検証してみた結果は以下の通りである。

この検証結果を踏まえて、消去法でclearfixの決定版を探っていこう。

まず、最初に候補から外れるのは、その4とその5のoverflowを用いた方法だ。値がautoではIE5.0がダメ（この表にはないがMac版IE5.xも）。hiddenでは、Netscape7.1がダメ。さらに、Netscape6ではauto、hiddenともにレイアウトくずれが発生する。また、IE6以前用にwidth: 100%としなければならないのも、同時にpaddingやborderが指定できない点で汎用的なクラスとしての使い勝手を狭めている。

と、ここまでは簡単なのだが、次のステップで早々につまづいてしまう。残りの3つとも、それぞれ一長一短があり、頭ひとつ抜けたものがないのだ。ブラウザへの対応状況を優先するなら文句なしに「height: 1%」だが、その意味不明の記述がどうしても引っかかる。しかし、ここで冒頭に掲げた決定版の定義をあらためて思い出して、強引に話を進めることにしよう。

まず、IE独自拡張のためvalidaterを通らない「zoom: 1」は外す。次に、IE5.0は無視することにして、「height: 1%」も外す。これで自動的に、IE向けclearfixの決定版は「display: inline-block」ということになった。しかも、inline-blockという値自体には、Operaでも、Safariでも、Mac版IEでもfloatクリア効果があるので、その目的で使用するのは理にかなったことともいえる。難は、すぐその後に「display: block」と続けなければならないところが、パッと見には「？」であることだが。

最後に、モダンブラウザ・IE両対応のclearfix決定版をまとめておこう。

次回は、Mac版IE向けclearfixの決定版を探り、このシリーズの最終回としたい。

これを、inline-blockに対応しているOperaと、対応していないFirefoxで表示させてみようと思うのだが、その前に、IEについて触れておかなければならない。最初に、inline-blockにちゃんと対応しているのは、OperaとSafari、Mac版IEくらいと書いたが、実はIE6.0以降もいちおう対応している。以下、「Internet Explorer 6 におけるCSSの拡張」より引用。

SPAN、B、および I などのインライン 要素は、width や height プロパティをサポートしません。標準準拠モードを有効にして、インライン 要素の width や height プロパティを設定するには、インライン 要素の display プロパティを inline-block に設定します。

要するに、ブロック要素をインライン要素的に扱うことはできないが、インライン要素をブロック要素的に扱うことはできる、ということである。これを踏まえ、Opera（9.21）、Firefox（2.0）、そしてIE（6.0）の3種類のブラウザで検証してみることにする。

●Operaの場合
inline-block完全対応のOperaでは、div要素がインライン要素的に横に並び、span要素がブロック要素的に幅と高さを持つ。結果、両方とも見た目的には同じになる。

●Firefoxの場合
inline-blockに対応していないFirefoxでは、div要素はブロック要素のまま、縦に積み重なり、span要素はインライン要素のまま、指定した幅・高さは無効になっている。

●IEの場合
変則的なのがこのIE。div要素にinline-blockを指定してもブロック要素のままだが、span要素にinline-blockを指定した場合は、ブロック要素的に幅と高さの指定が有効になる。

さて、ここまでは、まあ、はっきりいってどうでもいいことである。しょせん、Firefoxなどではiline-blockは使えないのだから。そもそも、なぜinline-blockに着目したかというと、いわゆるclearfixでIE7 & MacIE対策用にinline-blockが使われているからだ。しかし、floatのクリアにinline-blockが有効なのはIE7とMacIEだけではない。もともとinline-blockに完全対応しているOpera、Safariはもちろん、IE6でも、inline-blockでfloatをクリアできる。このことを次のソースを使って確認してみよう。

●Operaの場合
floatがクリアされているので、親ボックスに子ボックス（A、B）の高さが反映され、背景がきちんと表示されている。さらに、このセットを繰り返しているので、親ボックスはインラインに流し込まれ、横に並ぶ。

●IEの場合
こちらもfloatはクリアされているが、親ボックスはあくまでブロック要素として、横いっぱいに広がり、縦に並ぶ。

●Firefoxの場合
floatはクリアされないので、親ボックスに子ボックスの高さは反映されず、さらにボックスBの右に次のボックスが回り込んでしまう。

ここで、clearfixの記述を思い出してみよう。

IE7 & MacIE対策用にdisplay: inline-blockを指定した後、いわゆるバックスラッシュハックを使ってMacIEを除外した上で、display: blockに戻す。OperaやSafariでは、inline-blockのままでは具合が悪いからだ（MacIEでもinline-block指定による弊害がないわけではない。ブロック要素ではなくなってしまうので、例えばmargin: autoを使ったセンター揃えなどはできなくなってしまう）。

では、IE7はどうなるのか。IE7用にdisplay: inline-blockを指定しておいて、それをまたdisplay: blockに戻してしまうのはどういうことなのか。

実は、IE6以降では、いったんdisplay: inline-blockを指定して } で閉じた後、あらためてdisplay: blockとしても上書きされない、というか、floatのクリアに関してdisplay: inline-blockの指定は生きたままなのである（※）。試しに、先ほどのソースに、親ボックスへのdisplay: block指定を追加してみよう。

●Operaの場合
display: blockと上書きされ、Firefoxの時と同じ表示になる。

●IEの場合
display: inline-blockの指定が生きており、その2と表示は変わらない。

これはIEのバグなんだろうか、仕様なんだろうか。とにもかくにも、この奇妙な振る舞いのおかげで、inline-blockがclearfixにおけるＩＥ7対策として有効に機能しているわけだが、何だかスッキリしない話ではある。

※ } で閉じる前にdisplay: blockとすれば上書きされる。また、インライン要素にinline-block指定した場合は、 } で閉じた後でも、display: blockとすれば上書きされ、完全なブロック要素になる。

【追記】
inline-blockに対応しているのはIE6.0以降と書いたが、evolt.org - Browser Archiveより旧バージョンのIEを入手し、検証を試みたところ、インライン要素へのwidth、heightの指定についてはIE5.0以降、floatのクリアおよび「display: blockとしても上書きされない」という現象についてはIE5.5以降で確認できた。さらに、floatのクリアの件に関しては、hasLayoutというIE独自のプロパティが関係しているらしいこともわかってきた。

hasLayoutとは、IE（5.5以降）が内部的に持つ読み込みのみのプロパティで、その要素がレイアウトを持っているかどうかを示すもの。デフォルトの値はfalse（レイアウトを持っていない）で、ある種のCSSプロパティがトリガーとなって、true（レイアウトを持っている）となる。例えば、height（auto以外の値）、width（auto以外の値）、zoom（すべての値）などで、display（値がinline-blockの時）もそのひとつだ。そして、hasLayoutがtrueと判断されると、例のfloatがクリアされる（のと同じ）現象が起きるのである。いわゆるHolly Hackにおいてheight: 1%と記述するのも、このhasLayoutが背景にあるわけだ。

したがって、「display: blockとしても上書きされない」という件についても、display: inline-blockによって、いったんhasLayoutの値がtrueになると、再びdisplay: blockに戻しても（つまり上書きはされている）、hasLayoutはtrueのまま、ということなのだろうと想像できる。

# hasLayoutに関する参考ページ
hasLayout Property
HasLayout Overview

基本的な発想は上記の空ボックスによるクリアと同じだが、それをHTMLには一切手を加えず、スタイルシートだけで実現しているところに大きな特徴がある。しかし、ひとくちにclearfixといっても様々なバリエーションがあり、その記述のしかたは微妙に異なる。

一方、Movable Typeのデフォルトスタイルシートでもclearfixは採用されており、該当箇所だけ取り出すとこのようになっている（赤字はPosition Is Everything版clearfixと異なる部分）。

もちろんclearfixはこの2種類だけではない。いったいどのclearfixがベストなのか。まずは対象ブラウザをいわゆるモダンブラウザ（Firefox、Opera、Safari）に絞り込んで、clearfixの決定版を探っていきたいと思う。

検証のため共通で用意したスタイルシートとHTMLは以下の通り。

clearfixについては、:after擬似要素を用いた部分がモダンブラウザ用の記述なので、そのバリエーションを以下の10種類、用意した。

CASE 1は、Position Is Everything版clearfix と同じ記述。:after擬似要素にcontentを指定して、ボックス内要素の末尾にピリオドを追加、さらにそれを高さ0、不可視のブロック要素とし、clearを適用させる。最も一般的なスタイルだけに特に問題はないように思えるが、clearfixを適用させたボックスの高さをブラウザいっぱいにした時、ボトムにマージンが生じてしまうという不具合がある（ボックスを縦に積み重ねた場合は、マージンは生じない）。

以下、このCASE 1の記述をベースに、Movable Type版clearfixの設定を取り入れていく形でバリエーションを展開させていく。

CASE 2は、font-sizeの指定を追加した場合。ただし、Movable Type版clearfixとは変えて、0.1emでなく0とした。

CASE 3では、Movable Type版clearfixにならい、font-sizeを0.1emとした。

CASE 4は、font-sizeではなく、line-heightの指定を追加した場合。

CASE 5は、font-sizeとline-heightの指定を併記。ただし、font-sizeは0とした。

CASE 6は、Movable Type版clearfixと同様のfont-size、line-height指定を併記した場合。

CASE 7では、さらにMovable Type版clearfixに近づけ、heightを0.1pxとした。

CASE 8は、再び記述をCASE 1に戻した上で、追加する要素をMovable Type版clearfixにならいピリオドでなくスペースとした。

CASE 9は、スペースでなく、alt="" のように空にしてみた場合。

最後に、CASE 10では、空なら最初から高さもないし、不可視にする必要もないから、height、visibilityの指定を削除してみた。

以上、10通りのclearfixを、Firefox（バージョン2.0）、Opera（バージョン9.2）、Safari（バージョン1.0）、3種類のブラウザで検証した結果が以下の表である。○はマージンの発生なし、×はマージンの発生あり、△もマージンが発生するが×よりは小さい。さらに、△の数字は大きいほど生じるマージンは小さい、つまり○に近いということである。

Safariはバージョンが少々古いので、最新版では違う結果となるかもしれないが、ここから判断する限り、3ブラウザとも表示に不具合がないのは、CASE 8、CASE 9、CASE 10の3つ。中でも、記述のシンプルさ、論理性から、CASE 10がモダンブラウザ向けclearfixの決定版といえるのではないか。しかし、最初にclearfixを考えた人はなぜcontentをスペースや空でなくピリオドにしたんだろう。

【追記】
「clearfixを考えた人はなぜcontentをスペースや空でなくピリオドにしたんだろう」という問いについては、3ping.orgさんがおおよその解答を示してくれたが（トラックバック参照）、その後やっと問題のブラウザを特定できた。contentがスペースや空だとfloatをクリアできないのは、Netscapeだった。7.1で確認しているので、それより古いバージョンでも同様だろう。ただし、ここで検証したような親ボックスにborderまたはpaddingを設定したケースでは、floatがクリアされてしまうため見逃してしまったのだ（検証ページはこちら）。とはいえ、ピリオドにして、visibilityやらfont-sizeやらline-heightやら長々と記述するのは避けたい。そこで、少々反則かもしれないが、ピリオドの代わりに1×1ピクセルの透明GIFを用いたやり方を決定版としたいと思う。

font-sizeを%で指定した時のIE6の表示

まず、右のスクリーンショットを見てもらおう。

71%よりも72％の方が大きく、73%、74%と文字の大きさが変わらないのは、とりあえずいいとして、その上のサイズの75%になると、今度は逆に小さくなってしまうことがおわかりいただけると思う。その後、78%まで大きさは変わらず、79%でようやく72～74％と同じ大きさを回復する。

ただし、この現象が発生するのは条件が限られる。

• エンコーディング形式にかかわらず欧文フォントを指定したとき
• UTF-8でフォント指定なしのとき

逆にこの現象が起きないのは、

• エンコーディング形式にかかわらず和文フォントを指定したとき
• シフトJISでフォント指定なしのとき

フォント指定のあり、なしなど、いろいろと条件を変えて、UTF-8の場合とシフトJISの場合の2種類のサンプルページを用意したので、確認してみてほしい。

これはIEのバグとしか言いようがないと思うが、72%～74%と75%～78%のどちらの表示が間違っているというべきなのだろう。先ほどは、説明の流れの都合上、72%～74%について「とりあえずいい」としたが、Firefoxでの表示と見比べる限り、72%～74%の表示が変ということにしておきたい。

和文フォントを指定すれば、とりあえずこの問題を回避できるが、Verdanaを使えないのは非常に困る。そこで、仕方ないので、フォントサイズをパーセント指定するときは、72%、73%、74%は使わないようにしている。まあ、それで特に不都合なことはないだろう。

画像Aを背景に
ボックスBをセンタリングすると

 

こうなるはずだが…
こうなってしまう

全体の幅が100ピクセルで左右に1ピクセルの罫線を持つ画像Aを背景に指定し、表示位置センターで縦方向にタイルさせ、さらに、幅98ピクセルのボックスBをmarginの設定でセンタリングして配置した（→サンプルページ1）。

本来であれば、ボックスBは左右がピッタリ背景画像Aの中に収まるはずだが、Windows版のIE6.0では、背景画像Aが右に1ピクセルずれるため、背景画像Aの左の罫線の一部がボックスBに隠れて消えてしまう。

不明。しかし、Windows IE6.0でのみ発生するということは、このブラウザの、背景画像の表示位置に対する解釈がおかしいのではないか。しかし、相手が最もシェアの高いIEのしかも最新版では、ブラウザのせいという一言で片付けるわけにもいかない。

結局、背景画像の表示位置指定によるセンタリングはあきらめて、高さ100%のボックスで全体を囲み、そのボックスに対して背景画像を指定するしかない（→サンプルページ2）。その際、標準モードではボックスの高さを100％にすることはできないので、互換モードにする必要がある。したがって、一番いいのはこの手のレイアウトは最初からしないことだろう。

幅・高さとも50ピクセルで背景色が黒のテーブルをセンタリングさせるために、マージンを「margin: 0 auto」と上下左右まとめて設定してみた（→サンプルページ1）。しかし、各種ブラウザで検証したところ、Macintosh版のIE5.1、5.0ではセンタリングされないことがわかった。

Macintosh版IE5.1、5.0のバグと思われる。

上下左右まとめてではなく、「margin-right: auto; margin-left: auto」と設定すればOK（→サンプルページ2）。Windowsで作業していると気が付きにくいが、テーブルをセンタリングさせる時は、左右マージンを別々に設定すると覚えておこう。

どのような条件下においてこの現象が発生するか、細かく見ていこう。
まず、外部スタイルシートにおいて、box-A、box-B、box-C、box-Dという4つのボックスを定義する。いずれも、高さ・幅とも80ピクセル、背景色黒、文字色は白。ただし、box-Aとbox-Dの定義の前にはコメントなし。box-Bとbox-Cの定義の前にはコメントあり、前者には「構」、後者には「表」の1文字を入れた。
次に、HTMLファイルでは、テーブルを組んでbox-A、box-B、box-C、box-Dを横に並べ、それぞれのボックスの中に文字を入れた（→サンプルページ1）。
これをMacintosh版IE5.1で表示させるとこうなる（以下の図はすべてMacintosh版IE5.1によるスクリーンショット）。

外部スタイルシートの場合

ご覧のとおり、外部スタイルシートで定義した場合、コメントありのbox-B、box-Cは表示されない。box-Dがちゃんと表示されているところから見ると、「構」「表」などの文字が入ったコメント以降すべてのスタイル指定が無効となってしまうわけではないようだ。

HTMLにCSSを組み込んだ場合

また、コメントも含めてまったく同じスタイル定義をHTMLファイルの中に組み込んだとき（→サンプルページ2）のスクリーンショットがこれ。こちらは4つのボックスともちゃんと表示される。

問題を2つに切り分けて考える必要があるだろう。ひとつは、なぜコメントの中に「構」「表」などの文字があると、スタイル指定が無効になってしまうのか。もうひとつは、なぜ外部スタイルシートだと無効になって、HTMLの中に組み込んだ場合は大丈夫なのか。

まず、1番目の問題から考えてみる。「構」と「表」の共通点を探るべく、文字コード（Shift_JISコード）を調べてみると、「構」は8D5C、「表」は955C、つまり、5Cの部分が共通していることがわかった。さらに調べていくと、5Cは￥（円記号、ここでは都合上全角で表記している）に当たることもわかった。￥は、CGIプログラムなどでエスケープ処理をされる場合に使われる文字で、メタ文字と呼ばれる（この辺のことは、ウェブマスターのための文字化け講座に詳しい）。この￥が原因と考えて間違いないだろう。つまり、文字コードに含まれる5Cが￥と誤読され、その後のスタイル指定がエスケープされてしまうわけだ。

外部スタイルシートの場合：コメントに￥あり
HTMLにCSSを組み込んだ場合：コメントに￥あり

このことを検証するために、コメントの「構」と「表」を￥に変えた場合も試してみた。（→サンプルページ3）

やはり想像通りで、コメントに￥を入れると、HTMLの中にCSSを組み込んだ場合でもスタイル指定は無効になってしまう（→サンプルページ4）。

なお、文字コードに5Cを含むのは以下の37文字である（機種依存文字を除く）。
―ソЫ噂浬欺圭構蚕十申曾箪貼能表暴予禄兔喀媾彌拿杤歃濬畚秉綵臀藹觸軆鐔饅鷭

次に2番目の問題について検証する。HTMLの中にCSSを組み込むのと、外部スタイルシートの場合の違いは何だろうと考えていって思い当たるのが、文字コード宣言の有無だ。つまり、<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">というアレだが、DreamweaverなどのHTML作成ソフトを使っていると、自動的に文字コード宣言が挿入されるので入れ忘れることはない。しかし、外部スタイルシートで文字コード宣言が入っているのはあまり見たことがない。スタイルシートの場合は、@charset "shift_jis";とファイルの先頭に入れるらしく、さっそく実行してみた（→サンプルページ5）。

外部スタイルシートの場合：文字コード宣言あり

しかし、どうやら文字コード宣言の有無は、この問題には関係ないようだ。そもそも、この現象自体、Macintosh版のIEでのみ発生するもので、他のブラウザの場合は問題ない。また、本来、コメントに何が書かれていようとブラウザは飛ばし読みしてくれるはずで、それでもMacintosh版のIEでのみ不具合が起きるのは、ブラウザ側のバグというしかないだろう。

先に掲げた37文字を使わないことは当然だが、文字コードの5Cだけが問題なのか、他にも似たようなバグがあるのかわからないので、念のため、コメントには日本語を使わないのが安全・確実と考える。さらに、font-familyで日本語フォント（ＭＳ Ｐゴシック など）を使うなら、外部スタイルシートにも文字コード宣言をちゃんと入れておくのがベストである。

※注：簡単にいうと、文書型宣言の中の「URLあり」が標準モード、「URLなし」および文書型宣言そのものなしが互換モードとなる。詳しくはDTD（文書型宣言）とブラウザの表示モードを参照されたし。

Windows/IE6.0の場合
Windows/IE5.5の場合

この現象を実際に再現させてみよう。まず、文書型宣言はURLを含むフル表記。次に、スタイルシートで、body要素に対してフォントサイズを84％に設定した。テキストは、bodyタグ内に直接／divタグで囲んで／テーブル内に入れて／入れ子にしたテーブル内に入れて、の4通りで記述した（→サンプルページ1）。これをWindows版IE6.0で表示させた場合のスクリーンショットが上。Windows版IE5.5で表示させた時のスクリーンショットが下。Windows版IE5.5では、テーブル内の文字に84％のサイズ指定は効かず、デフォルトに戻ってしまう。

すでに概略のところで述べたとおり、ブラウザのバージョンによるスタイルシートの解釈の違いが原因。せっかく、URLもきちんと書いて、validなHTMLを心がけているのに、そのことがかえって仇となってしまう。

古いブラウザでも新しいブラウザと同じように表示させることはできない。しかし、その逆、つまり、新しいブラウザでも古いブラウザと同じように表示させることはできる。要するに、互換モードで表示させるということだ。

まず、文書型宣言からURLを抜く。次に、テーブル内の文字も縮小されるように、body要素に対してだけでなく、td要素に対してもフォントサイズを84％に設定する。この時気になるのが、そうするとテーブルを入れ子にした場合、84％×84％で、さらに文字が縮小されてしまうのではないかということ。しかし、幸いなことに、tableタグが入るたびにフォントサイズ指定は白紙に戻されてしまうようで、84％×84％とはならない（→サンプルページ2）。ケガの功名というか、互換モードではテーブル内の文字にフォントサイズ指定が継承されないといういい加減さが逆に好都合な結果を生んでいるわけだ。もっとも、解決法が互換モードというのは何だかスッキリしないのだが。

widthを指定しないことによる不具合はいくつかあると思うが、ここでは2つのケースを取り上げる。

ひとつは、floatさせたいボックスにtext-alignを指定した場合。たとえば、画像の下にキャプションを右揃えで入れ、その左側に本文を回り込ませたいときなどだ。この形にするためには、画像とキャプションを含むボックスにfloat:rightとtext-align:rightを指定することになるが、そうした時、Macintosh版IEでは本文が回り込まずに画像の下に来てしまう（→サンプルページ1）。これは、text-align:centerとしても同様である。

もうひとつは、divタグを入れ子にした場合。上記と同じケースで、さらに画像とキャプションの間隔も細かく指定したいときなどは、画像を含むボックスの中にさらにキャプションを含むボックスを入れ、画像とのマージンを設定することになるが、この場合もMacintosh版IEでは本文が回り込まない（→サンプルページ2）。

最初からタネを明かしているように、いずれもwidthを指定すれば解決する（→サンプルページ3／サンプルページ4）。

Mac/IE5.1の場合

右のスクリーンショットを見てもらおう。左側に10ピクセルの余白をとってコンテンツA、その右にコンテンツB、というような2段組のレイアウトを組んだとする。スタイルシートでは、コンテンツAに float: left、margin-left: 10px と指定する。ちゃんと正しい位置に配置されているかわかるように背景画像に10ピクセル刻みで縦の罫線を入れてみた。ご覧のとおりMac（およびNetscape6.0以降）では位置のズレはない。

Windows/IE6.0の場合

しかし、Windows版のIE5.5、6.0ではコンテンツAの位置がずれ、余白は10ピクセルより広くなってしまう（→サンプルページ1）。右にマージンをとり、コンテンツBを左に回り込ませた場合も同様である（→サンプルページ2）。指定したマージンに対してどれくらいずれるか、マージンの数字を変えて試してみたところ、ほぼ指定したマージンの2倍になるようだ。

"float" とは、直訳すれば「浮かぶ」もしくは「浮かせる」という意味である。これがなぜ回り込みの指定になるのか、ピンとこないのだが、今回のようなケースを検証していると、何となくわかったような気がしてこないでもない。つまり、floatとは指定した要素とそれに続く要素を無重力状態の中にプカリと浮かせるようなものなのではないか。そして、float: leftとすると要素は左に寄ろうとし、float: rightとすると右に寄ろうとする。したがって、floatを指定した要素はフワフワと浮いているようなものだから、marginを設定して位置を横にずらそうとすると、指定した位置でピタリと止まらずに必要以上に動いてしまうのではないかと想像される。

この現象がすべてのOS/ブラウザで等しく同条件で発生するなら、あらかじめズレを織り込んで指定すればよいだけの話だが、Netscape6.0以降やMacでは発生しないためそうはいかない。したがって、ひとつの要素に対してmarginとfloatを同時に設定しないようにするしかないだろう。

そこで、コンテンツAとコンテンツBの左右配置については、「要素を左右に隙間なく配置することができない」のところで検証した2番目の方法を採用し、全体の幅を固定するためのボックス（#both-content）に対して左マージンを設定した（→サンプル3）。

ボックスA

 

ボックスB

 

Netscape7.1の場合のスクリーンショット

単純化するために、AとB、高さの異なるボックスを2つ設定した（A＞B）。そして、ボックスAをfloat: leftで左側に配置、ボックスBをfloat: rightで右側に配置、さらに全体をひとつのボックス（クラス名: column）で囲み、それを2回繰り返してみた（→サンプルページ1）。Winows版IEでは問題ないのでOKと思ってしまいそうだが、実はそれ以外のブラウザではちゃんと表示されない。

レイアウトがくずれるのは、全体を囲むボックスを繰り返す前に回り込みを解除していないせいである。にもかかわらず、Windows版IEでは正しく表示されてしまうのは、そちらの方がおかしいというべきだろう。

解決法は2つある。ひとつは、「原因」で指摘している回り込みの解除を用いる方法（→サンプル2）。ただ、「HTMLは論理構造を記述し、見栄えはスタイルシートで定義する」という本来のあり方からすると、HTMLの中にレイアウトを制御する以外まったく意味を持たない要素が入り込んでくるのはやや気になる。
もうひとつは、全体を囲むボックスに高さを与える方法（→サンプル3）。ただし、コンテンツがテキスト主体で、高さを特定できない場合はこの方法を使えないのが難点である。

この現象を検証するために、左右それぞれの半円画像を背景とするボックスを設定し、floatを使って横に配置した。意図するところは、左右ピッタリくっつけて完全な円にしたいということなのだが、Windows版のIEでは間に3ピクセルほどの隙間ができてしまう。（→サンプルページ1）

もともとfloatは写真などの画像にテキストを回り込ませるような使い方を想定して作られたプロパティと思われるため、Windows版のIEではfloatさせる要素と回り込ませる要素の間に自動的にマージンをとってしまうようだ。

floatを使うことを前提にした場合、次の2つの方法が考えられる。
(1) 右に配置する要素も左にfloatさせる（→サンプルページ2）

(2) 右に配置する要素は右にfloatさせ、全体の幅を固定する（→サンプルページ3）

こうしたいのだが…
こうなってしまう

これを実現したいのは、例えば、背景画像の下辺に合わせてテキストを乗せたい時などだ。そこで、ボックスに図のような三角形の画像を背景として入れ、vertical-align: bottomと指定した。しかし、ボックス内のテキストは上揃えになったままである（→サンプルページ1）。同様に、middleを指定してもテキストを中央に配置することはできない。

仕様というしかない。そもそもvertical-alignは、画像やテキストなどのインライン要素か、テーブルのセルに対して指定するのが本来の使い方のようだ。

テーブルを使う以外に方法はないだろう。（→サンプルページ2）