W3C home > Mailing lists > Public > www-style@w3.org > October 2009

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 09 Oct 2009 11:29:34 +0200
Message-ID: <4ACF027E.1030303@moonhenge.net>
To: Bert Bos <bert@w3.org>
CC: "www-style@w3.org" <www-style@w3.org>
Bert Bos wrote:
> On Monday 05 October 2009, 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 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.
>
> I know what it is trying to say, but I agree that "other side" isn't
> very clear unless you happen to have the same mental model of floats as
> the authors of this paragraph many years back...
>
> The context is as follows. Imagine a line of text, where ### is an
> image:
>
>     One two three ### four five six.
>
> Now float that image to the left:
>
>     #### One two three four five six.
>
> and note that the words "One two three" have moved to the *other side*
> of the image!
>
> Yes, that is not very precise language. It talks about moving, but
> nothing moves in CSS and the text never was at the left side to begin
> with. But as you can see in other instances in that same section of the
> spec, some people naturally visualize CSS as a process that moves boxes
> into place one by one, while others think of CSS as a formula that
> yields a single solution for all boxes all at once.

Oh, for me the phrases "moving" and "other side" weren't the problem.
(I guess I have the same mental model of floats as the authors!)  I
think it's clear what it's saying, despite not being very precise.

>
> The phrase "first available" is there to remind us that the content on
> that hypothetical "current line" that existed before we moved the float
> into place, may not all fit on the same line anymore afterwards. E.g.,
> if the result is
>
>     ###  One
>     ###  two
>     ###  three
>     four five
>     six.
>
> then the first available line box for the word "two" was not
> the "current line," but the line after it.

This is the problem.  As I said in my previous post, modern browsers
follow what 9.5 says:

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

So it seems to me that the situation

      ###  One
      ###  two
      ###  three
      four five
      six.

cannot arise, since the very fact that the in-flow image was able to fit
on the same line as One two three:

One two three #### [...] |

means that there must be space on the same line for the prior content
after the image has been floated:

####One two three [...]  |

so the "first available line" for the prior content is the current line.
This was the point I wanted to make in my first post.


Had it been the case that the image didn't fit:

One two three       |
########## four five|
six seven eight nine|
ten                 |

then floating it left yields

One two three four  |
##########five six  |
seven eight nine ten|


In this case -- and this was the point I was making in my second post --
despite the spec saying:

   # Any content in the current line before a floated box is reflowed in
   # the first available line on the other side of the float.

we see in the case above that the prior content isn't reflowed at all.

Moreover, the explicit float rules in 9.5.1 don't mention this
dependence on "fitting" at all.  Whilst this wouldn't be the only
instance of the behaviour definition being split across multiple
sections(;-), in this particular case 9.5 explicitly defers to the rules
in 9.5.1 and so probably shouldn't contain new information not found there.


Note that it could of course be a SPAN of several inline boxes being
floated:

One two three SP SP |
four five six seven |

becomes

SP SPOne two three  |
four five six seven |

and

One two three SPAN  |
SPAN SPAN five six  |
seven eight nine ten|

becomes

One two three four  |
SPAN SPAN SPANfive  |
six seven eight nine|
ten                 |

But the result is the same.


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





>
>>> [1] http://www.w3.org/TR/CSS2/visuren.html#floats
>
>
>
> Bert
Received on Friday, 9 October 2009 09:31:47 GMT

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