(unknown charset) Re: [CSS21] float rules when interacting with floats outside containing block

Bert Bos wrote:
> On Wednesday 28 January 2009, 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.
>> There's a significant case here where browsers don't actually match
>> what the rules say.  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.
> On inspection, however, it doesn't seem to be related to the rules for 
> float placement. Even normal text content (i.e., line boxes) fails to 
> be pushed down in some cases.

> Compare these two cases. (I put them together in one attachment, if you 
> want to try.) The only difference is that the second example has a 
> wider margin.
>     <div style="float: right; width: 20em">
>       Float right
>     </div>
>     <div style="margin-right: 19em">
>       Averylongwordthatcannotbebrokenandthuswillcauseoverflow
>     </div>
> and
>     <div style="float: right; width: 20em">
>       Float right
>     </div>
>     <div style="margin-right: 21em">
>       Averylongwordthatcannotbebrokenandthuswillcauseoverflow
>     </div>
> The example has a DIV that floats and another DIV that is a normal block 
> with normal text. If you make the window narrower, at some point there 
> will not be enough room next to the float and the text will be pushed 
> down to under the float...
> ... except that in the second example, the text is *not* pushed down by 
> the major browsers. Apparently they forgot to consider the case of a 
> line box that is wider than the content box :-(

Maybe.  But I'm still not convinced that the behaviour seen in the
browsers is undesirable.  As before, this behaviour depends on whether
or not the float intersects the content area of the block containing the

I tend to think of overflow as being independent of other layout
considerations, which is to say that I don't expect layout to change
when I switch between hidden, auto, scroll and visible overflow (with
the exception of scrollbars, which themselves do not affect boxes
outside the containing block).  According to the spec, however, when the
float does not intersect, the former three values of overflow do not
cause any line box movements yet switching overflow to visible suddenly
causes the overflowing line box to move down below the float. (When the
float /does/ intersect, the line box consistently moves down in all four

I agree with David Hyatt, though, in that none of this seems terribly

Anton Prowse

Received on Monday, 9 March 2009 18:52:10 UTC