与Chrome和Firefox不同的是，当在没有宽度的浮动div中浮动孩子时。

Question

我在这里做了个测试

http://jsfiddle.net/WZyF7/11/

在计算宽度方面，Firefox似乎与Chrome和IE7-9不同。它没有给内容提供它所需要的足够大的宽度，而是使div尽可能宽，是最宽的子元素。这将元素垂直叠加在FF中，而在其他浏览器中则是水平叠加。

有没有办法使所有浏览器在不设置父元素的宽度或使用JS的情况下以相同的方式处理这个问题？有没有人确切地知道这是如何跨浏览器计算的呢？(宽度:auto；？)

Answer 1

相关的规范位是http://www.w3.org/TR/CSS21/visuren.html#floats，其中写着：

表的边框、块级替换的元素或正常流中建立新块格式上下文的元素(例如具有“可视”以外的“溢出”的元素)不得与元素本身在同一块格式上下文中的任何浮动框重叠。如果有必要，实现应该清除所述元素，将其置于任何前面的浮点数之下，但如果有足够的空间，则可以将其与该元素相邻。它们甚至可能使所述元素的边框比第10.3.3节所界定的范围更窄。CSS2没有定义UA何时可以将所述元素放置在浮点数的旁边，或者根据所述元素可能变得更窄的程度来定义。

而在http://www.w3.org/TR/CSS21/visudet.html#float-width中，这部分内容是：

如果“宽度”被计算为“自动”，则使用的值是“收缩至适合”的宽度。

还有后续行动。请注意，实际计算的首选宽度，这是重要的，这里，不是所有的定义很好。因此，基本上，在这种情况下，每个规范的行为都是没有定义的。

无论如何，这里发生的情况是，火狐给overflow: hidden块应有的宽度，每节10.3.3，然后清除它通过浮点，而Chrome和IE似乎采取了“他们可能甚至”的路径。特别是，它假设在计算父级的首选宽度时会这样做。

尽管如此，我认为Firefox的行为在这种特殊的情况下是正确的:您的“容器”是400 in宽。“父”有20 of的水平填充。“浮动”的宽度为300 is。"content“有20 of的水平填充。这为“内容”中的文本留下了60 of的宽度，但是最长的单词(“available.”)我的字体大概有70便士宽。例如，在Chrome中，“内容”与“浮动”相邻的唯一方法是，“内容”的正确填充完全消失。如果你给“父”一个固定的宽度，火狐也会做同样的事情.当然，你是在强迫一个宽度，而不是要求浏览器通过收缩包装算法选择一个合理的宽度。

您最好的选择是给“父”一个特定的宽度，如果您想要它的宽度，而不是依靠收缩包装产生的宽度实际上太小的内容。