ここにテストを設定しました
Firefox は幅の計算方法が Chrome や IE7-9 と異なるようです。コンテンツに必要な幅を与える代わりに、div を最も広い子要素と同じ幅にします。これにより、FF では要素が垂直方向にスタックされますが、他のブラウザーでは要素が水平方向にスタックされます。
親要素に幅を設定したり、JS を使用したりせずに、すべてのブラウザーでこれを同じ方法で処理する方法はありますか? そして、ブラウザ間でこれがどのように計算されるかについて正確に情報を持っている人はいますか? (幅: 自動; ? )
関連するスペックビットはhttp://www.w3.org/TR/CSS21/visuren.html#floatsで、次のようになっています。
テーブルの境界ボックス、ブロックレベルで置き換えられた要素、または新しいブロックフォーマットコンテキストを確立する通常のフローの要素（「可視」以外の「オーバーフロー」を持つ要素など）は、のマージンボックスと重なってはなりません。要素自体と同じブロックフォーマットコンテキスト内のフロート。必要に応じて、実装は、先行するフロートの下に配置することで上記の要素をクリアする必要がありますが、十分なスペースがある場合は、そのようなフロートに隣接して配置することができます。それらは、セクション10.3.3で定義されているよりも、上記の要素の境界ボックスを狭くすることさえあります。CSS2は、UAがフロートの隣に上記の要素を配置できる時期や、上記の要素がどれだけ狭くなる可能性があるかを定義していません。
そして、http ：//www.w3.org/TR/CSS21/visudet.html#float-widthの次の部分：
「width」が「auto」として計算される場合、使用される値は「shrink-to-fit」幅です。
以降。ここで重要な優先幅の実際の計算は、それほど明確に定義されていないことに注意してください。したがって、基本的に、この状況での仕様ごとの動作は定義されていません。
いずれにせよ、ここで起こっていることは、Firefoxがoverflow: hiddenセクション10.3.3に従ってブロックに必要な幅を与えてから、フロートを超えてクリアしているのに対し、ChromeとIEは「彼らも」の道を進んでいるようです。特に、親の優先幅を計算するときにそれが行われることを前提としています。
そうは言っても、Firefoxの動作は、この特定の狭いケースの方が正しいと思います。「コンテナ」の幅は400ピクセルです。「親」には20pxの水平方向のパディングがあります。「フローティング」の幅は300ピクセルです。「コンテンツ」には20pxの水平方向のパディングがあります。これにより、「コンテンツ」内のテキストの幅は60ピクセルになりますが、私のフォントでは、最長の単語（「利用可能...」）の幅は約70ピクセルです。たとえば、Chromeでは、「コンテンツ」が「フローティング」の横に収まる唯一の方法は、「コンテンツ」の右側のパディングが完全に消えるためです。ここで「親」に固定幅を指定した場合、Firefoxは同じことを行います。ただし、もちろん、シュリンクラップアルゴリズムを介して適切な幅を選択するようにブラウザに要求する代わりに、幅を強制します。 。
ここでの最善の策は、シュリンクラップに依存してコンテンツに対して実際には小さすぎる幅を生成するのではなく、「親」に特定の幅を指定することです。