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

On 23/08/2013 6:31 AM, L. David Baron wrote:
> On Thursday 2013-08-22 18:48 +1000, Alan Gresley wrote:
>> Hello,
>>
>> 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

[snipped, test case above is redundant, now replaced with 
containing-block-ltr3.htm]

>> Are my conclusions correct? Does IE10 do right in respects to the spec?
>
> I think this is an issue for which we very nearly changed CSS 2.1
> because nobody had implemented it correctly, and then the Microsoft
> folks said they had.  However, there are really three separate
> issues, related to the interaction of rules 3, 5, and 7 with the
> containing block of the float not intersecting the floats that need
> to be flowed around.
>
> I think the chronology was roughly:
>
>    Multiple browsers fixed the interaction with rule 5, I think because
>    Hixie wrote a test for it long ago.
>
>    IE10 fixed the interaction with rules 3 and 5.
>
>    Nobody has fixed the interaction with rule 7.
>
> But more details and a bunch of links that should help with the
> history of the issue are in
> https://bugzilla.mozilla.org/show_bug.cgi?id=616334 .
>
> -David

Thank you David. This relates to the old CS2.1 Issue 101 [1]. The IE10 
behavior where it follows rule 3 can be the result of two different sets 
of styles for the parent that is in the normal flow. What happens is the 
parent flows upwards and sits beside a float higher up in the source but 
since something is restricting the width of this parent (a declared 
width or a side margin), IE allows for this but also follows rule 3 by 
positioning the later float below the float that is higher in the source 
where the other UAs allow for the later float to overlap the float that 
is higher in the source and thus, breaking rule 3.

Looking back over the old threads in the archives of this mailing list 
regarding issue 101, I see that I mentioned about some magical 
"containing block" having box edges (e.g. content, border and margin) 
[2]. This was because of your test case with a side margin and my own 
test cases (one with a fluid design which is copied at the end of this 
message [4].

http://dbaron.org/css/test/2009/float-outside-tests/rule-3-left

http://css-class.com/test/css/box/floats/containing-block-ltr3.htm

Both test cases has the inner parent's hypothetical “border box” (I 
don't know what else to call it or how else to refer to it, see also the 
allowable styles shown below) width restricted. In your test case, the 
is due to a margin-right and in my test case, this is due to a declared 
width.


Your test case has an opposite but matching behavior for IE10 being a 
right float clearing a left float due to a margin left where my test 
case has an opposite but matching behavior for IE10 being a right float 
clearing a left float due to inline base direction of rtl.

http://dbaron.org/css/test/2009/float-outside-tests/rule-3-right

http://css-class.com/test/css/box/floats/containing-block-rtl3.htm


For my ltr test case, the allowable styles below still allows FF, Chrome 
and Opera to have the left float to overlap the right float that is 
higher in the source.

  width: 200px;

  width: 190px; padding-left: 10px;

  width: 190px; border-left: 10px solid red;

  width: 200px; padding-right: 10px;

  width: 200px; border-right: 10px solid red;


I believe analogous behavior would apply for test cases with rtr. Since 
the width of the padding-right and border-right does effect the behavior 
in FF, Chrome and Opera (by still showing and overlap of floats), then 
it's not easy solved by contemplating about a hypothetical “padding box” 
or a hypothetical “border box” for a containing block.


Another similar test case but where just FF is alone in behavior is with 
display:table.

http://css-class.com/test/css/box/floats/containing-block4.htm


I believe that something should be decided since we can't necessary 
control how authors abuse CSS but at the same time, we must consider 
cases where such authors have abuse CSS and have layouts broken when a 
UA changes behavior (see bug report in this list message [3]). At the 
very least, we can't have an ongoing situation where some UAs are 
failing test in the CSS2.1 testsuite.

Alan


1. http://wiki.csswg.org/spec/css2.1#issue-101
2. http://lists.w3.org/Archives/Public/www-style/2010Oct/0526.html
3. http://lists.w3.org/Archives/Public/www-style/2009Jan/0445.html
4. Copied test case below (IE10, IE9, IE8 and IE7 all had the same 
behavior):


<!DOCTYPE html>
<div style="float:right; width:150px; height:50px; background:red;"></div>
<div style="width: 250px; background: blue; border-right: 300px solid
yellow;">
   <div style="background: aqua;">width of containing block is this
aqua box</div>
   <div style="float:left; width:350px; height:150px; background:lime;
"></div>
</div>
<div style="background:orange;">text text text text</div>


The right floating box only drops when it reaches the content edge of
the containing block of the left floating box (green).


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

Received on Friday, 23 August 2013 12:09:55 UTC