Re: [CSS21] line boxes next to floats in different containing blocks

fantasai wrote:
> On 08/24/2009 01:36 PM, Anton Prowse wrote:
>> [3] http://dev.moonhenge.net/css21/test-cases/floats/line-boxes,floats,containing-blocks-1.html
>> [7] http://dev.moonhenge.net/css21/test-cases/floats/line-boxes,floats,containing-blocks-4.html 



>> The only relevant text in the current version of the CSS21 spec is the
>> following quote from 9.5 (Floats).[6] It is clear that this part of the
>> specification only gives detailed consideration to floats in the same
>> containing block as the line boxes. Given that Opera's behaviour is
>> clearly wrong, and Safari's seems to depend on strange conditions, which
>> of the two other behaviours (if any) is correct and/or meaningful? The
>> spirit of the current spec seems to correspond to the behaviour of
>> Firefox/IE8 (certainly, floats in the same block formatting context but
>> in different containing blocks must not universally be ignored), but in
>> either case the description of the flowing of line boxes around the
>> float needs rewording and clarification. [In fact, it does anyway since
>> the heuristic for determining whether a float fits on the current line
>> is incorrect (email to follow).]
> 
> Where does the spec imply that consideration is given only to floats
> in the same containing block as the line boxes? AFAICT it only talks
> about floats and line boxes *after* the float, which could include
> those outside its containing block.

Well, I said it only gives /detailed/ consideration to floats in the
same containing block as the line boxes, an opinion based on the fact
that the sketchy description of the rules for flowing line boxes around
floats is insufficient to explain how to render the other case
comprehensively (and in fact needs a fair bit of cleaning up even to
explain the former case, although it's clear from the choice of wording
that this was the case that the author had in mind).

   # A float is a box that is shifted to the left or right on the current
   # line.

...within its containing block, right?  (Petty point: it's only shifted
if it happens to not already be in the correct position.)

   # The most interesting characteristic of a float (or "floated"
   # or "floating" box) is that content may flow along its side (or be
   # prohibited from doing so by the 'clear' property). Content flows
   # down the right side of a left-floated box and down the left side of
   # a right-floated box.

...and prohibited from flowing down the other side?  This would be
consistent of the Fx/IE8 rendering of [3] (and the IE8 rendering of
[7]).  Does this prohibition apply if the line box's float-side edge
isn't actually incident with the margin area of the float, due to its
containing block not intersecting or abutting the float?  IE8 thinks
so, but Fx3 doesn't.  If it does apply, I personally don't regard the
content as "flowing down the side of the float" and so the wording
doesn't seem to fully describe that situation.

   # Since a float is not in the flow, non-positioned block boxes created
   # before and after the float box flow vertically as if the float
   # didn't exist. However, line boxes created next to the float are
   # shortened to make room for the margin box of the float.

... and are not permitted to be divided into multiple shortened pieces,
such as in the case of
        _____________          ____________
       | ----------- |        | ---------- |
______||           ||________||          ||__________
|text ||right-float||        ||left-float|| ???????? |
------||           ||--------||          ||----------
       ||___________||        ||          ||
        -------------         ||__________||
                              ------------

where the two floats are in containing blocks that straddle a wide
paragraph?  That seems reasonable, although it either needs to be stated
that the unique shortened line box is situated in the /earliest/
possible point on the line, or else stated that -- since the content is
no longer flowing down the right side of the left float -- the
prohibition rule outweighs the opportunity to flow.

   # If a shortened line box is too small to contain any further content,
   # then it is shifted downward until either it fits or there are no
   # more floats present.

(Shifted downwards, yes... but "fits" is ambiguous since the amount of
shortening is not fixed but rather varies according to the floats
present.  The question is whether the /content/ fits, not the line box.
The ambiguity in this wording exists even in the more usual case of
floats and line boxes in the same containing block.)

   # Any content in the current line before a floated box
   # is reflowed in the first available line on the other side of the
   # float. In other words, if inline boxes are placed on the line before
   # a left float is encountered that fits in the remaining line box
   # space, the left float is placed on that line, aligned with the top
   # of the line box, and then the inline boxes already on the line are
   # moved accordingly to the right of the float (the right being the
   # other side of the left float) and vice versa for rtl and right
   # floats.

There are several problems here, even for the "same containing block"
case.[See, for example, my post
http://lists.w3.org/Archives/Public/www-style/2009Oct/0289.html,
response to "Paragraph 3"]  If one is careful, I think it's possible to
achieve a rewording that works also for the "different containing block"
case.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Wednesday, 24 March 2010 07:04:53 UTC