- From: (unknown charset) Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 09 Mar 2009 19:51:19 +0100
- To: (unknown charset) www-style@w3.org
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 overflow. 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 cases.) I agree with David Hyatt, though, in that none of this seems terribly important. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Monday, 9 March 2009 18:52:10 UTC