Re: Floater inside of floater sizing

On 19/06/2014 1:50 AM, L. David Baron wrote:
> 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

David, this is not just relating to a floated parent. The same result 
happens in Chrome with a non floated parent with a declared width. See 
the third test down.

http://css-class.com/test/temp/float-with-inline-block.htm

Here is the code:

<div style="background-color: red; width: 400px;">

   <div style="display: inline-block; width:  200px; background-color: 
blue;">inline-block (1)</div>
   <div style="float: left; width: 200px; background-color: 
green;">float-child (2)</div>

</div>

In section 9.5.1 is the following:

   | 8. A floating box must be placed as high
   | as possible.

Chrome is not doing this.

Alan


-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Wednesday, 18 June 2014 16:27:01 UTC