Re: [CSS21] Issue 192 - floats and shortened line boxes

On 04/03/2011 01:06, Bert Bos wrote:
> (Issue 192 is tracked at http://wiki.csswg.org/spec/css2.1#issue-192)
>
> On Wednesday) 01 September 2010 21:19:56 Anton Prowse wrote:
>>    From the f2f minutes[1]:
>>> <glazou>
>>> http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html
>>>
>>>    dbaron: Anton's proposal for issue 1 looks fine.
>>>    dbaron: I don't think we want to make the second change.
>>>    dsinger: I think the "further" lacks a referent.
>>>    <fantasai>  dbaron proposes s/further content/content after the
>>>    float/<fantasai>  and s/it/that content/
>>>    TabAtkins: And the third issue is invalid - Bert gave an example
>>>    where
>>>
>>>               the content may have to be reflowed onto multiple
>>>               lines.
>>>
>>>    RESOLVED: Accept change for first issue, accept dbarons' change
>>>    for
>>>
>>>              the second issue, third issue is invalid.
>>
>> I don't believe the third issue to be invalid, and I went into rather
>> a lot of detail in a later post[2] in the cited thread, in addition
>> to responding[3,4] to the purported counter-example that Bert
>> raised[5]. If Bert has a counter-example that he has not posted to
>> the list, please could he do so.
>
> The spec says:
>
>      Any content in the current line before a floated box is reflowed
>      in the first available line on the other side of the float.
>
> That is indeed only true if the box floats to the left (or to the right
> in rtl text), otherwise the content stays visually "on this side" of the
> float. The next sentence in the spec ("In other words...") says it more
> clearly. This is text from 1998 and it is also in a section that says it
> is merely an introduction, not the exact rules. We wouldn't write like
> that anymore, but given that the exact rules are there as well, I don't
> think it hurts.

Indeed, but the "on the other side" isn't what's being objected to in 
Issue 192 (although it does need fixing).


> I said previously that "first available" referred to the fact that the
> text before the float might have to be broken over multiple lines. That
> was a mistake, as you pointed out. The first available line ("line box"
> might be better) is always just one line.

Indeed, and it's the /same/ line.  That is, prior content never gets 
pushed downwards.


> [...]
>> I also disagree with dbaron's change for issue 2, since the sentence
>> in the spec is talking about moving line boxes (ie creating a gap
>> between line boxes) not about flowing content (which is adequately
>> handled by the preceding sentence in the spec), as David himself
>> noted in [6].
>
> I think that is the question here: do we move line boxes or content?
>
> What we want is that the *content* moves, viz., to the next line box
> that is wide enough to hold it (or the first line box that isn't
> shortened, whichever comes first). The shortened line boxes remain where
> they are. They just happen to stay empty.
>
> David's rewrite removes the treacherous word "it" from the old text and
> makes the referent explicit:
>
>      If a shortened line box is too small to contain any content after
>      the float, then *that content* [my emphasis. BB] is shifted downward
>      until either it fits or there are no more floats present.
>
> There are no doubt still better ways to express it, but this does the
> trick.

>> Also, as I've pointed out before, 9.4.2 (Inline Formatting Context)
>> incorrectly says "Line boxes are stacked with no vertical separation"
>> so that needs editing too.
>
> No, that remains true, even in the presence of floats. It may look as if
> there is space between the lines, but actually the space is made up of
> empty line boxes. (The space is always an integral number times the
> 'line-height'.)

Woah, that's a completely different model to the one I have always 
assumed. You're saying that empty line boxes exist, stacked one atop the 
other.  That doesn't fit in with the spec at all:

9.4.2:

   # Line boxes that contain no text, no preserved white space, no
   # inline elements with non-zero margins, padding, or borders, and no
   # other in-flow content (such as images, inline blocks or inline
   # tables), and do not end with a line feed must be treated as
   # zero-height line boxes.

(which is subject to Issue 199).

It's also not supported by browsers, since the pushed-down content 
always sits flush with the bottom of the float, not flush with some line 
box grid:

<!DOCTYPE html>
<div style="width:15em; line-height:10px">
 text text text text text text text text text text text text text text 
text text text text
 <div style="width:10em; float:left; height:15px; background:yellow"></div>
 supercalifragilisticexpialodocious
</div>


>> In any case, the suggested phrase "content after the
>> float" is ambiguous: it wants to refer to content after the float's
>> placeholder, but can easily be misinterpreted as content prior to
>> the placeholder which has moved to the other side of the float.
>
> True, but if you actually try to work from that interpretation, you'll
> soon run into contradictions: A shortened line box next to a right-
> floating image can never contain anything "after" in the sense of "to
> the right of" that image. So "after" has to refer to the logical, not
> the visual order.

OK.


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

Received on Friday, 4 March 2011 09:43:08 UTC