- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 22 Sep 2010 22:09:37 -0400
- 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. -Boris
Received on Thursday, 23 September 2010 02:10:15 UTC