- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 18 Jun 2014 08:50:40 -0700
- To: Bogdan Brinza <bbrinza@microsoft.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <20140618155040.GA21668@crum.dbaron.org>
On Tuesday 2014-06-17 23:21 +0000, Bogdan Brinza wrote: > Another interoperability problem we've uncovered while investigating compatibility problems reported to Internet Explorer. This was found on few internal sites, but should affect every site with same combination, and we expect this is pretty common: > > Consider the following reduction: http://jsfiddle.net/boggydigital/6M2yu/ (Seems to be down right now, at least for me.) > If a floater contains inline-block element and a floater next to it - Chrome would break the line after the first element and sizes container as if line break didn't happen, even though there should be enough space to fit the child floating element without breaking the line. > > Internet Explorer and Firefox fit both elements without a line break. Is this the expected behavior? Officially, there is no expected behavior, because we don't have a spec defining intrinsic sizing, and the question is really a question about intrinsic size calculation of a block that contains floats (which in this case happens to itself be a float). There's an early draft of a spec at http://dev.w3.org/csswg/css-sizing/#block-intrinsic which says that the element should be sized as though there is no line break, which based on your description disagrees with all three browsers you tested. But it's an early spec draft that isn't ready to be interpreted at this level of detail yet; we should figure out the right behavior and put it in the spec. Essentially, the problem is that handling floats is one of the deficiencies of the model of doing intrinsic width calculation in a functional way rather than doing it using a pseudo-layout at an "infinite width" (as Gecko and IE used to do). In particular, while the calculation of min-content width is easy (assume that the floats are never next to anything else), the calculation of the max-content width needs to use heuristics to determine which floats should be considered "next to" which inline content. The heuristics used by browsers relate to both order of the content and to the 'clear' property. They're also probably somewhat difficult to figure out by testing, so if we want to sort this out it would be useful to write up descriptions of what each browser does based on examination of the code. (I'd be willing to write up a description for Gecko.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Received on Wednesday, 18 June 2014 15:51:30 UTC