在Chrome和Firefox中显示不同的呈现方式，当浮动的div没有宽度时浮动。 [英] Different rendering from Chrome and Firefox when having floated children in a floated div with no width.
问题描述
我在这里设置了测试
Firefox似乎与Chrome和IE7-9的不同之处在于如何计算宽度。而不是给内容尽可能多的宽度，因为它使div是最宽的子元素。
Firefox seems to differ from Chrome and IE7-9 on how to calculate the width. Instead of giving the content as much width as it needs, it makes the div as wide it's widest child element. This stacks the elements vertically in FF, while horizontally in other browsers.
有没有办法让所有浏览器以相同的方式处理这些元素，而不必为父元素设置宽度或使用JS？有没有人有关于这是如何计算跨浏览器的信息？ （width：auto;？）
Is there any way to make all browsers handle this the same way without setting a width to the parent element or using JS? And does anyone have information on exactly how this is calculated across browsers? (width:auto; ? )
推荐答案
相关规格位为 http://www.w3.org/TR/CSS21/visuren.html#floats 其中：
一个表的边框，块级替换的元素，或者正常流中的一个元素，它建立一个新的块格式化上下文（例如元素与可见之外的溢出）不能与元素本身在同一块格式化上下文中的任何浮点的边框框重叠。如果必要，实现应该通过将所述元素放置在任何前面的浮动之下来清除所述元素，但是如果存在足够的空间，则可以将其放置在这样的浮动附近。他们甚至可以使所述元素的边框比第10.3.3节定义的更窄。 CSS2不定义何时UA可以将所述元素放置在浮点旁边或所述元素可以变得更窄。
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
http://www.w3.org/TR/CSS21/visudet.html#float-width ，其中说：
如果'width'计算为'auto'，则使用的值是缩小到适合的宽度。
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
及以下。注意，优选宽度的实际计算，这是重要的在这里，并不是所有明确定义。
and following. Note that the actual computation of preferred width, which is what matters here, is not all that well defined. So basically, per spec behavior in this situation is undefined.
在任何情况下，这里发生的是Firefox提供 overflow：hidden 阻塞它应该有10.3.3节的宽度，然后清除它通过浮动，而Chrome和IE似乎采取他们甚至的路径。特别是，它假设它会计算父的首选宽度。
In any case, what's happening here is that Firefox is giving the overflow: hidden block the width it should have per section 10.3.3 and then clearing it past the float, while Chrome and IE seem to take the "they may even" path. And in particular, it's assuming it will do that when computing the preferred width of the parent.
这么说，我认为Firefox的行为在这个特定的狭窄case：你的container是400px宽。 parent有20px的水平填充。 浮动宽度为300像素。 content有20px的水平填充。对于content内的文本留下60px的宽度，但是最长的单词（available ...）对于我的字体大约70px。例如，在Chrome中，内容适合浮动的唯一方式是因为内容的右侧填充完全消失。 Firefox会做同样的事情，如果你给这里的父一个固定的宽度，但然后你强迫一个宽度，而不是要求浏览器通过收缩包装算法选择一个合理的。
All that said, I think the Firefox behavior is more correct in this particular narrow case: your "container" is 400px wide. The "parent" has 20px of horizontal padding. The "floated" is 300px wide. The "content" has 20px of horizontal padding. That leaves 60px of width for the text inside "content", but the longest word ("available...") is about 70px wide with my fonts. In Chrome, for example, the only way "content" fits next to the "floated" is because the right padding of the "content" disappears entirely. Firefox will do the same thing if you give a fixed width to the "parent" here.... but then you're forcing a width, instead of asking the browser to pick a reasonable one via the shrink-wrap algorithm, of course.
这里最好的方法是给父一个特定的宽度，如果你想要有这个宽度，而不是依靠收缩包装产生宽度实际上对于内容太小。
Your best bet here is to just give the "parent" a specific width if you want it to have that width, instead of relying on shrink-wrapping to produce a width that's actually too small for the content.
这篇关于在Chrome和Firefox中显示不同的呈现方式，当浮动的div没有宽度时浮动。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
