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

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.  This can happen because there's a
> width or margin on the inner block, in situations like this:
>
>
>    +----------------------------------------------------------+
>
>    | Block A                                                  |
>    |
>    | +--------+                                               |
>    |
>    | |Float in|                                               |
>    | |Block A |     +----------------------------------------+|
>    | |
>    | |        |     | Block B                                ||
>
> The question is whether we consider the "Float in Block A" when
> placing floats whose containing block is Block B (which has a big
> left margin).
>
> This question affects three of the rules for positioning floats:
> rule (3), rule (5), and rule (7).  I wrote testcases for these
> cases:
>   http://dbaron.org/css/test/2009/float-outside-tests/
> (I tried to make the testcases show what was going on visually, at
> the cost of making them a drop more complicated.  I'm not sure if
> that was worth it.)

Trust David Baron to find unexpected bugs in browsers!

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.

Maybe it's an over-aggressive code optimization: a programmer thought 
that if a box doesn't overlap a float, then the box's content won't 
overlap the float either...

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 :-(


If you replace the long word by a left float, you get David Baron's 
example, which shows the same bug.

Prince seems slightly better than the browsers, because it does at least 
push down floats correctly. Maybe it doesn't apply the 
same "optimization" to floating child boxes as to other children.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France