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

Re: Issue 192 Summarization

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 04 Mar 2011 10:41:16 +0100
Message-ID: <4D70B3BC.4040206@moonhenge.net>
To: www-style list <www-style@w3.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>
On 03/03/2011 23:54, Tab Atkins Jr. wrote:
> Sorry for the massive delay, but this email is to resolve my action to
> summarize the discussion around Issue 192
> <http://wiki.csswg.org/spec/css2.1#issue-192>.
> First, I will address issue 3 in
> <http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html>.
> The current text in section 9.5 reads:
> # Any content in the current line before a
> # floated box is reflowed in the first available
> # line on the other side of the float.
> Anton objected that the phrase "first available line" here wasn't
> necessary, as the content preceding the float in the document will
> always continue to fit on the line that it previous fit on.
> The issue here is subtle.  Bert presented an example in
> <http://lists.w3.org/Archives/Public/www-style/2009Oct/0050.html>
> showing how text would be flowed if the float takes up too much room,
> such that not all the content that source-preceded the floating
> element on the line could fit.
> Anton objected to the possibility of this case, but his objection was
> invalid - the situation described by Bert can indeed exist, but it's
> resolved in a different way than Bert suggested.  This is illustrated
> in<http://software.hixie.ch/utilities/js/live-dom-viewer/saved/860>:
> the span changes its width when floated (as inline elements don't
> respect 'width', but floats do).

In what way was my objection invalid?  As I responded in [1,2], Bert's 
example was of an inline image, which didn't fit on the same line as the 
preceding text prior to floating it and hence was not relevant to the 
point he was trying to make.

Your example refers to the case where the element to be floated sits on 
the same line as preceding content prior to floating it, but when 
floated it has a width larger than its natural width.  In my quick 
response to Bert, I was assuming it went without saying that in this 
case you have to consider the element to be floated as if it had that 
width prior to floating.  (In other words, you must consider it as if it 
were an inline image or similar.)  I *did* discuss this exact case in 
detail as Relationship 2 in [3,4], however, which is what browsers 
actually implement:

> All browsers agree, though, that
> this is resolved by instead pushing the float down to the next line.

> Anton presented another example which illustrates the problem perhaps
> more starkly, which I have reproduced in
> <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/859>.  In
> this example, the multi-word span originally breaks across two lines.
> Floats can't do this, so it collects its descendants into a fresh
> embedded inline layout context.  This would make the float large
> enough to push some of the source-preceding content to the next line,
> but again browsers instead push the float to the next line.
> Source-following content is then flowed in the earliest possible
> position - the dark blue word, which source-follows the float, moves
> to the first line, visually preceding the float, while the middle-blue
> word drops to the third line.

Again, this is Relationship 2 in [3,4].

> Conclusion:  The spec is indeed incorrect here - it doesn't match
> implementation reality.  Floats *never* push source-preceding content
> to a different line, consistently across browsers.  (This remains true
> even when left and right floats are mixed, and source order is played
> with.)  If a float ever *would* do so, the float is instead pushed
> down to the next line.  Source-following content then flows to fill
> the space in the preceding line (if the float was pushed down), the
> current line, and the following lines.
> I'm not sure, without a lot of thought, what edits would be required
> to Section 9.5 of CSS 2.1 to make this work properly.

I don't think it's so difficult to codify Relationship 2... provided 
we're prepared to introduce placeholders.  It'll be tough without them 
though!  Also don't forget my troublesome last example in [3] ;-)

[1] http://lists.w3.org/Archives/Public/www-style/2009Oct/0055.html
[2] http://lists.w3.org/Archives/Public/www-style/2009Oct/0057.html
[3] http://lists.w3.org/Archives/Public/www-style/2010Aug/0181.html
[4] http://lists.w3.org/Archives/Public/www-style/2010Sep/0053.html

Anton Prowse
Received on Friday, 4 March 2011 09:41:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC