W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Action Item: Fix Float Positioning Rules for floats in run-ins

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 22 Sep 2010 22:09:37 -0400
Message-ID: <4C9AB6E1.10701@mit.edu>
To: Stephen Zilles <szilles@adobe.com>
CC: "www-style@w3.org list" <www-style@w3.org>
On 9/22/10 10:03 PM, Stephen Zilles wrote:
>>     <span style="display: run-in">
>>       <span style="float: left" id="one"></span>
>>     </span>
>>     <span style="float: left" id="two"></span>
>>     <div></div>

> [SZ] I was not tasked with solving the "paint" issue. For the above test case to behave as you suggest, there would have to be a sibling block element (say with "id=three") following the<span>  with id=two.

There is such a sibling.  See the testcase.

> In that case the the run-in would become the first child of that block element and the source tree would be (effectively) re-ordered.

No, not really.  What's reordered is the rendering model (which is not a 
tree, etc, if you believe Bert).

> With that caveat, I agree with your reading of the paint order

My "reading" is what the paint order "should" be if everything were 
sane. It's NOT what the spec currently says to do, since where floats go 
in the "rendering tree" is even more undefined than most things about 
the "rendering tree".

In other words, the behavior of the above testcase is currently 
undefined in the spec, as far as I can see.

> because the block which receives the run-in would paint after the float as I understand things.

The block paints both before and after the float, depending on which 
part of the block you're looking at.  I'm concerned with the float 
descendant of the run-in, not with the block.

Received on Thursday, 23 September 2010 02:10:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC