- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Wed, 11 Aug 2010 06:01:13 +1000
- To: www-style@w3.org
On Tue, Aug 10, 2010 at 11:43:19AM -0700, Tab Atkins Jr. wrote:
> On Tue, Aug 10, 2010 at 11:34 AM, Peter Moulder
> <peter.moulder@monash.edu> wrote:
> > block
> > run-in Doesn't run in
> > inline
> > block
> >
> > That last example is particularly interesting, and I believe it conflicts with
> > 9.2.3 if one reads 9.2.3 as just making statements about the final box tree:
> > the run-in box doesn't contain a block[-level] box, so (1) doesn't apply; and
> > a sibling block box (that does not float and is not absolutely positioned)
> > follows the run-in box [viz. the anonymous block box], yet the run-in box
> > hasn't become the first inline box of that block box.
>
> I don't understand your explanation here. In the final box tree the
> run-in still has an inline sibling - the inline element is broken
> around the block, generating an inline box, then a block box, and then
> an inline box.
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.
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.
Maybe we could say that it's not a conflict because it's no longer a run-in box,
but that would still point to a changing box tree where run-in boxes initially
exist but end up not existing.
pjrm.
Received on Tuesday, 10 August 2010 20:01:45 UTC