W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: Floater inside of floater sizing

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC