[CSS21] display:run-in clarifications

I was looking at section 9.2.3 preparatory to trying to implement it, 
and ran into several things that are underspecified.  A test file that I 
was using (just basic tests; no attempt to test DOM mutation) is attached.

Specific issues I ran into, and the behavior in Opera and IE8 for those 
issues (Webkit's implementation is so broken on the easy cases that it 
doesn't seem worth worrying about how they handle the edge cases):

ISSUE 1:

The section is written in terms of the concept of "block box", which 
doesn't seem to be defined.  The word "block" links to the section on 
block-level elements, but that talks about the fact that some elements 
are block-level and that some of them generate block boxes.  Notably, 
tables do not.  Furthermore, section 9.2.4 talks about elements with 
"display:inline-block" generating "a block box".

The observed behavior here in IE8 and Opera seems to be the following:

1) For purposes of rule 1, a "block box" seems to be a block-level box 
in Opera.  In particular, this test:

    <span style="display: run-in"><span style="display: 
inline-block">a</span></span>
    <span style="display: block">b</span>

runs the run-in into the block.  Same for inline-table.  Both do NOT run 
the run-in into the block in IE8.  In both browsers a display:block or 
display:table child forces the run-in to be a block.  I did not test 
more complicated child setups yet (inlines containing display:block, 
other run-ins, list-item, etc).

2) For purposes of rule 2, both browsers seem to define "block box" as 
display equal to "block" or "list-item".  Neither one runs a run-in into 
a display:table box that comes after it.  Neither one runs a run-in into 
a display:inline-block box that comes after it.  Neither one runs a 
run-in into a display:run-in box that comes after it, even if the latter 
generates a block box.  This last part (running into run-ins) is the 
only part of the above that's clearly described by the spec, as far as I 
can see.

ISSUE 2:

"follows" is not defined (similar to the issues we had for anonymous 
table objects).  In practice, the behavior in both browsers is that 
spaces coming between the element with display:run-in and the following 
element with display:block are ignored unless white-space:pre (and maybe 
some other values; I didn't test) is set.  Elements with float:left and 
position:absolute are not ignored, however; if such an element comes 
between an element with display:run-in and the following display:block 
element, the run-in becomes a block.  I did not test other float or 
position values, but I assume right and fixed behave the same way. 
Elements with display:none are ignored.

ISSUE 3:

For rule 2, "starts with a run-in" is not defined.  In particular, it's 
not clear whether a block that has a run-in child and a block child, 
such that the run-in runs into the block child, "starts with a run-in". 
  Or whether a block that has a run-in child that gets a block box 
counts.  As far as I can tell from Opera's and IE8's behavior, they 
interpret "starts with a run-in" as meaning "has a first child box that 
is an inline box generated by a previous display:run-in sibling".

PROPOSED RESOLUTION FOR THE ISSUES:

I cannot give a variant of rule 1 that will match both IE's and Opera's 
behavior.  We need a decision here as to what the rule actually means. 
My personal preference would be that a run-in with a block-level child 
box becomes a block box (Opera's behavior).

For rule 2, it sounds like we should define "follows" in some sane way 
that matches the above behavior (possibly reusing the equivalent 
definitions for table anonymous objects, but making sure to cover all 
the cases in terms of whitespace, out-of-flow elements, etc).  Then we 
should define that the run-in runs in if the following sibling is a 
non-replaced element with display:block or display:list-item, unless 
that following sibling starts with a run-in.  We should define "starts 
with a run-in" as I do above under ISSUE 3, or equivalent.

I would be happy to convert the attached test file into testcases, add 
some dynamic mutation tests, and check the whole thing into the CSS2.1 
test suite once we sort out what behavior we want for rule 1.

Feedback, or comments on what I missed in the two implementations I 
looked at, much appreciated,
Boris