Re: [CSS21] Trivial editorial issues with 9.5 (Floats)

L. David Baron wrote:
> On Monday 2009-10-05 18:34 +0200, Anton Prowse wrote:
>> Some trivial editorial issues with 9.5 (Floats):[1]
> 
>> Issue 2:
>>
>>   # However, line boxes created next to the float are shortened to make
>>   # room for the margin box of the float. 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.
>>
>> Delete "further"
>> (No prior content is referred to.)
> 
> I think the prior content in question is the content before the
> float.

Ah, that's probable. But this situation is peculiar to the the first
line, and "further" makes no sense to me for subsequent shortened line
boxes.

> If the content before the float doesn't fit, then the float is instead
> moved down below the line.
(... and the line containing that prior content then continues to be fed
inline content until full, and then the shortening process takes place
with subsequent line boxes.)

Actually, the spec views this from exactly the opposite direction: that
if the /float/ doesn't fit next to the prior content, it is instead
moved down below the line.  The difference is crucial, and only when
attempting to reply to you did I notice that the problem here is
technical (or, if editorial, non-trivial).

9.5.1[2] states:

   # 6. The outer top of an element's floating box may not be higher than
   # the top of any line-box containing a box generated by an element
   # earlier in the source document.
   # [..]
   # 8. A floating box must be placed as high as possible.

which, in the absence of any other relevant rules in that list, means
that the outer top of the float is horizontally aligned with the top of
the line box in which its first inline box would sit if it were not floated.

But this is not what the (normative?) overview in 9.5 says (nor what the
modern browsers do):

   # 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.

(my emphasis).  Here, the line on which the float "starts" is determined
by whether it would fit on the same line as all the "prior" content.
This idea is not captured in the explicit rules of 9.5.1.

> 
>> Issue 3:
>>
>>   # Any content in the current line before a floated box is reflowed in
>>   # the first available line on the other side of the float.
>>
>> When is the first available line anything other than the current line?
>> If never, then s/first available/same/
> 
> This sentence doesn't make sense to me either way; I'm not sure what
> it's trying to say.

In the case that the float fits on the current "line", the prior content
has to be reflowed on the other side (in a shortened line box).  In this
case, "the first available line on the other side of the float" is
actually the same line.

I was assuming that the spec was worded to allow for the possibility
that the prior content be reflowed at some lower position, which in fact
cannot occur.  But actually, there's the opposite problem which I didn't
notice originally, in which -- assuming that 9.5 and current browser
behaviour reflect what the spec /wants/ to say -- the float doesn't fit
on the current line and so moves to the line below.  In this situation,
"the content in the current line before a floated box" is not reflowed
at all (and is possibly joined by other inline content).

(Is this what you meant when you said the sentence made no sense to you?)

>> [1] http://www.w3.org/TR/CSS2/visuren.html#floats
[2] http://www.w3.org/TR/CSS2/visuren.html#float-position

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

Received on Monday, 5 October 2009 18:44:39 UTC