- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 10 Aug 2010 16:14:32 -0400
- To: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org
On 8/10/10 4:01 PM, Peter Moulder wrote: > I believe the final box tree has the run-in as a block box, followed by > an anonymous block box that contains the first half of the inline element, > followed by the block, followed by an anonymous block box that contains > the second half of the inline element: > > block > run-in-became-block > anon block 1 > inline part 1 > block > anon block 2 > inline part 2 > > That box tree is consistent with line breaking and border rendering at least. Yes, this is the only box tree that makes sense. > If that is the tree, then anon block 1 is a sibling block box (that does not > float and is not absolutely positioned) that follows the run-in box. But run-ins don't run into anon block boxes (except for a while there in Webkit). That needs to be true no matter what, because of this situation: <div> <span style="display: run-in">Run</span> in </div> That needs to render as: Run in instead of Runin Of course there have been a whole bunch of changes decided on for the run-in text that don't seem to have made their way into any sort of publicly available draft... so maybe everyone is operating on old spec text here? Note that last I checked whether a run-in runs in or not was defined entirely in terms of the element tree, by the way. There are certainly tests in the test suite along the lines of my markup above at this point; it may be worth to add tests along the lines of yours, but they're fundamentally the same thing, it seems to me. -Boris
Received on Tuesday, 10 August 2010 20:15:06 UTC