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

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)

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 20:56:46 UTC