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

Re: [CSS21] float rules when interacting with floats outside containing block

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 02 Feb 2009 23:48:42 +0100
Message-ID: <4987784A.4070402@moonhenge.net>
To: www-style@w3.org

Anton Prowse wrote:
> 
> L. David Baron wrote:
>> In CSS 2.1, the rules in
>> http://www.w3.org/TR/CSS21/visuren.html#float-position define the
>> position on floats relative to all earlier floats within the same
>> block formatting context.  This means they do require consideration
>> of other floats that are in the same block formatting context, but
>> not within the containing block.
> 
>> The question is whether to consider earlier
>> floats that are in the same block formatting context, but whose
>> horizontal coordinates do not overlap the horizontal coordinates of
>> the new float's containing block.  This can happen because there's a
>> width or margin on the inner block
> 
>> This question affects three of the rules for positioning floats:
>> rule (3), rule (5), and rule (7).
>>   Firefox 3.1beta, Opera 9.63, and Safari 3.2.1 all show the exact
>>   same behavior:
>>     + do NOT consider the float for rule 3
>>     + do consider the float for rule 5
>>     + do NOT consider the float for rule 7.
> 
>> the rules that allow displacing block formatting contexts in
>> http://www.w3.org/TR/CSS21/visuren.html#floats
> [...]
>> all four browsers mentioned disagree with the "must
>> not overlap" rule
> 
> Note however that if the preceding floats even partly intersect the 
> content area of the containing block of the new float, all the rules 
> /are/ applied in all browsers mentioned except Safari which applies all 
> the float rules but not the BFC rule. (And except IE7, which cannot 
> allow the containing block to overlap the preceding floats due to its 
> hasLayout model.)
> 
> IE8-RC1 shares the behaviour of Firefox in all the situations under 
> discussion here.
> 
> The situation in which three of the four rules are broken arises because 
> the new float overflows its containing block, and informally speaking 
> the part of this float which is outside of its containing block's border 
> area appears not to enter into calculations concerning float overlap. --(i)

Sorry, in the above paragraph I meant to say "the part of this float
which is outside if its containing block's /content/ area" (ie, the
overflow).

> This status quo strikes me as reasonable behaviour except for Safari's 
> treatment of the BFC rule. And it is consistent with the idea that 
> visible overflow should in some sense be impotent.
> 
>> It seems like we should probably adjust the spec for these cases,
> although I'm not exactly sure how.
> 
> Is it confined to a matter of formalizing (i) above, or is there more 
> depth to the current behaviour than that?
> 
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
Received on Monday, 2 February 2009 22:49:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:16 GMT