- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 02 Feb 2009 23:48:42 +0100
- 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 UTC