W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: [CSS21] Another ambiguity in the definition of "containing block"

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 29 Sep 2009 18:50:40 -0700
Message-ID: <4AC2B970.4040206@inkedblade.net>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style list <www-style@w3.org>
Boris Zbarsky wrote:
> Consider the following testcase:
> <!DOCTYPE html>
> <body>
>   <div style="height: 200px;">
>     Text
>     <div style="float: left; height: 50%; width: 100px;
>                 background: green"></div>
>     More text
>     <div>x</div>
>     Text
>     <div style="float: left; height: 50%; width: 100px;
>                 background: orange"></div>
>     More text
>   </div>
> </body>
> In current browsers I see the following behavior:
> Gecko: Two floating 100px by 100px squares (one green, one orange).
> Opera 10: As Gecko.
> IE8: As Gecko.
> Webkit: No visible squares; the offsetHeight of the floating divs is 
> reported as 0.
> If the "<div>x</div>" is removed, then Webkit's rendering changes to 
> match the other browsers.
> I believe the issue is a disagreement over section 10.1 item 2.  Webkit 
> is using the anonymous block box created per section to contain 
> the text as the containing block for the float.  If one assumes that the 
> float and the text around it have the same ancestor boxes (which seems 
> like an eminently reasonable assumption), then this interpretation makes 
> sense.  If this item is not actually talking about boxes but rather 
> means "the box generated by the nearest block-level ancestor element", 
> then it's just ambiguous as to which box is meant here.

I think the spec should be clarified to say that anonymous block boxes
are never considered to be the containing block of other block boxes.
I believe it is the spec's intention that the creation of anonymous
blocks and inlines should not affect the rendering in any visible way.
I imagine an author would be very confused if the the insertion of a
div in one part of a block causes a float in another part to size itself
in a completely different way.

> I still think that all of 10.1 is ambiguous in any but the most trivial 
> cases that fall under item 2; this is just another example....

Would you like to propose text for a rewrite?

Received on Wednesday, 30 September 2009 01:51:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC