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

Issue 192 Summarization

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 3 Mar 2011 14:54:00 -0800
Message-ID: <AANLkTikhL8wCNFPJmwaTNP4Uc8+Wwj8i49pff=8PXejz@mail.gmail.com>
To: www-style list <www-style@w3.org>
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).  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.

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.

~TJ
Received on Thursday, 3 March 2011 22:54:52 GMT

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