W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Thu, 17 Mar 2011 03:08:32 +0100
Message-ID: <4D816D20.4000400@moonhenge.net>
To: www-style@w3.org
CC: "L. David Baron" <dbaron@dbaron.org>
FWIW, I've not found David's comments to be off-target. Quite the 
reverse, his latest posts show that he's come to the same conclusions 
using the same logic as I did.  Despite the vast quantity of 
correspondence on these float issues, let's remind ourselves of the tiny 
proposals that I'm making.

As far as the line box shortening, content fitting, content shifting to 
one side of the float, etc etc issues are concerned (which is the 
subject of this thread), I have no problem with the rules in 9.5.1.

The problem is merely the sloppy/misleading text in 9.5:

I originally wrote:
> 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.)

Basically, a line box only exists at all next to a float if it contains 
content; and a line box is only shifted downwards if, at its current 
position, it cannot contain the initial piece of content that would be 
flowed into it without overflowing its containing block.  The first 
shortened line box associated with a given float always contains the 
content prior to the float without needing to reflow that content into 
multiple lines (this is Issue 3, below); this line box never needs 
shifting downwards.  For subsequent shortened line boxes, the content 
they contain comes after the float in the document tree and so the word 
"further" lacks a referent.  What this sentence in the spec should 
really be saying is
s/further content/content without overflowing its containing block/
so whilst deleting "further" is an improvement, explicitly mentioning 
the avoidance of overflow is even better.

The issue really isn't any deeper than that.


> 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/

David and I both used the logic of Rules 6 and 8 in 9.5.1 to conclude 
that the content before the float is indeed always reflowed into the 
same line on the other side of the float; it's never broken into 
multiple line boxes.  All I'm requesting, then, is that the spec be 
cleaned up to remove that "first available" because it is 
confusing/misleading, implying that in some circumstances the line on 
the other side of the float might somehow not be available or that the 
content might need splitting.


The only extra thing which came up during the thread is my curious test 
case that I made explicit in [1].  It's possible for floated content to 
*only just* not fit on the line containing prior content if it weren't 
floated, but to fit next to that line when floated.  This is in keeping 
with Rules 6 and 8.  It means, however, that the first sentence of 9.5 
is problematic:

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

The "current line" in the case just described is the first line, not the 
second.  Basically, we ought to define "current line", eg as the 
earliest line that the float fits on without causing prior content to be 
reflowed into multiple line boxes, thus providing a reciprocal nod back 
to Rules 6 and 8.  I'm not sure it's worth the hassle though; I think we 
should just chalk it up as another editorial glitch in 9.5 and rewrite 
the whole float thing in CSS3.


In summary then, all I'm asking for is the minimal edit suggested for 
each of issues #2 and #3, the justification for the former being found 
in this post and the justification for the latter being found in David's 
and my earlier posts.


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Thursday, 17 March 2011 02:09:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT