Re: [CSS21] Left float later in source does not clear right float due to nesting of containing block

A short reply. I will expand more in my reply to David.

On 23/08/2013 5:58 AM, Morten Stenshorne wrote:

> Alan Gresley <alan@css-class.com> writes:
>
>> I have been reviewing some old offline bug folders and found an old
>> test case.
>>
>> http://css-class.com/test/css/box/floats/containing-block2.htm
>>
>> All UAs tested (IE10, Opera 12.14, FF23 and Chrome 28) will show fine
>> if the inner parent (see id=leftparent) in normal flow does not have a
>> fixed width.
>
> Or, more precisely, it shows fine if the left float's containing block
> has a width that makes it intersect with the right float. As far as I
> can tell.
>
>> If the inner parent in normal flow does have a fixed width, I believe
>> that only IE10 shows the test case correctly.
>
> It sure looks like IE10 is the only one getting it right.
>
> http://www.w3.org/TR/CSS21/visuren.html#float-rules
>
>     Rule 3: The right outer edge of a left-floating box may not be to the
>     right of the left outer edge of any right-floating box that is next to
>     it. [...]
>
> But really, while I think IE's rendering is the only one that makes
> sense, how could three independent browser engines manage to come up
> with the same bug? :) I'm amazed. Are we missing something?

No, upon David reply, I see this is CSS2.1 Issue 101 (from 2010) coming 
up again to haunt us.

>> FF and Opera shows the same regardless of if the inner parent has a
>> width or auto width.
>
> That's not what I observe. With auto width (or a width larger than
> 200px), the left float is put below the right float, like in IE.

I can not reproduce the behavior in IE10 so I not sure what was 
happening or what I did. My test case has an extra inflow containing 
block that is unnecessary. It may have been testing odd behavior in 
other UAs that has now been fixed.

>> Chrome does not like the test case so it paints the right float above
>> the text that is contained within the next float in the source.
>
> Could be some optimization that messes up painting order, maybe.

For me, when UAs do this, it shows that the checking of certain 
variables by different methods in a build produces odd behavior when UA 
are required to follow the spec but can't since the spec has overlooked 
something.

>> Are my conclusions correct? Does IE10 do right in respects to the spec?
>
> Common sense + what I could find in the spec right now seems to suggest
> that only IE gets this right. But I still find it strange that the three
> others are bug-compatible.

See CSS2.1 Issue 101 [1] and this message by David in 2009 [2].


1. http://wiki.csswg.org/spec/css2.1#issue-101
2. http://lists.w3.org/Archives/Public/www-style/2009Jan/0445.html


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

Received on Friday, 23 August 2013 07:33:45 UTC