Re: [CSS21] display:run-in clarifications

Bert Bos wrote:
> The document tree that CSS works on is a very simple tree that is based 
> on SGML's ESIS, but omits lots of things, such as PIs, all information 
> about entities, comments, character encoding, and everything related to 
> DTDs. Basically, the tree consist of just elements, attributes and text 
> strings, augmented with pseudo-classes and replaced elements.

OK.  That's fine.  That just makes the document tree a proper subset of 
the DOM tree in the case I'm interested in, as you point out later.

> Elements are nodes in the tree. They have a name, a parent, and zero or 
> more IDs. Unlike SGML & XML, CSS allows there to be more than one ID 
> per element. Also, the names aren't restricted to SGML name tokens. 
> Elements come in two types: replaced or not. If elements are replaced, 
> they may have an intrinsic width, height and/or aspect ratio; if they 
> are not, they have zero or more children.

Where is this last part defined?  In particular, where is it defined 
that replaced elements have no children?  I see nothing about that in 
conform.html.  There's text that says they're outside the scope of the 
formatting model, but that says nothing (to me) about what the element 
tree looks like.

I would be fine with making this definition explicitly (probably in the 
replaced element section in conform.html), and given it all of my issues 
with replaced elements in the proposed run-in specification go away, I 
think.  But we do need to make this definition then.

> The document tree is not related to the DOM, except in the fact that the 
> DOM also resembles the ESIS and infoset, and resembles them 
> sufficiently that UAs that implement both CSS and the DOM can often use 
> the DOM (after enhancing it with the equivalents of pseudo-classes and 
> pseudo-elements) as a superset of the tree that CSS needs.

Right.

> CSS talks about "parent box" (in four places, I think), but that is just 
> for brevity. It should be read as "box generated by the parent of the 
> element that generated this box" with the implicit assumption that 
> there is only one such box or that it is clear which one is meant 
> otherwise.

Another definition worth making, if so.  It's not clear to me that which 
one is meant is actually clear at those places, but inline layout is not 
really my area of expertise, so I'll assume they're ok enough.

That said, CSS also talks about "ancestor box", again without defining 
it.  Presumably an "ancestor box" is a "box generated by an ancestor of 
the element that generated this box"?  If so, the behavior for run-in 
doesn't look great to me.  For example, consider this markup:

<div style="display: block; width: 100px; background: green">
   <div style="display: run-in">
     <div style="display: inline-block; width: 50%; background:red">
       x
     </div>
   </div>
   <div style="display: block; width: 50px"></div>
</div>

If I use the above definition of "ancestor box", then the containing 
block of the inline-block is going to be the div with width 100px (per
section 10.1 rule 2).  The inline-block will then end up with a width of 
50px.  I think it would make a lot more sense to use the div with width 
50px as the containing block, and in fact that's what Webkit and Opera 
do.  IE8 uses the div with width 100px, looks like.

I should also note that there are other situations (e.g. 
block-inside-table-row) where it's not quite clear what should be going 
on with containing blocks if the above definition of "ancestor box" is 
used; in particular it's not clear to me which element generates the 
anonymous table-cell box and its block child in that case.

Note that CSS also uses the words "sibling box" in various places.  And 
"child box" in some cases (presumably to mean "a box that has this box 
as its 'parent box'"?).  So while boxes may not form a tree, one can 
still talk meaningfully about the set of child boxes of a box, 
apparently.  We could define the replaced element generated content 
behavior for run-ins in those terms, maybe.  Or just leave it undefined 
for now, of course (which it would be in practice anyway; the only 
question is how many parts of the spec would need to be updated when it 
_is_ finally defined).

Sorry to harp on all this, by the way, but I'd really like to get the 
specified behavior of run-in pinned down before actually shipping an 
implementation...  I really appreciate the time you're spending on this 
issue!

> (If CSS 2.1 sometimes seems to have been written in a particularly 
> sloppy and ambiguous way, remember that most of the text dates from 
> 1997-1998 and was re-written prior to publication by a technical 
> writer. Moreover, it has undergone more than ten years of patches by 
> many different people, which improved precision locally, but didn't do 
> much for the overall consistency. In fact, many of these patches 
> weren't meant to improve the spec, they were meant to permit common 
> implementation bugs to persist, so that the spec would become a W3C 
> Recommendation sooner...)

Sure.  I guess the question is whether we can fix these ambiguities at 
this stage.  Parts of your mail would be an excellent addition to 
conform.html, I think.

So to sum up what I think is the current state of things as far as 
run-in goes.

1)  I think we should explicitly define that as far as conform.html
     goes replaced elements have no children.  Once this is done, I
     believe we have a more or less complete definition of when run-ins
     run in; the remaining issue is generated content on replaced
     elements which I think we should either explicitly leave undefined
     (and say so) or define in some way that will automatically work
     sanely once the box generation for that case is defined.
2)  Need to figure out what should be happening with containing blocks
     for descendants of the run-in; that includes all descendants that
     do something with the 'width' property (absolutely positioned,
     floated, inline-block, inline-table, replaced element).
3)  Need to figure out how inheritance works, and in particular how it
     works when run-in interacts with first-line and first-letter.

-Boris

Received on Wednesday, 2 September 2009 23:03:56 UTC