Re: [CSS21] display:run-in clarifications

Bert Bos wrote:
> That's one of those things that are so obvious to me that it never even 
> occurred to me that it could be ambiguous. :-) No problem making it 
> clearer, of course. How about, under "Replaced element" in 3.1:
> 
>     [...] or applet. In the document tree[1], a replaced element is
>     therefore represented as empty[2]. For example, [...]

Sounds good.

>>      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.
> 
> At the moment I know of no way to define after/before on replaced 
> elements in such a way that we can still refine it later.

I meant define run-in in such a way so that no matter what the behavior 
ends up being for :before/:after on replaced elements the run-in section 
wouldn't need changing.  If we're not defining it in terms of child 
boxes, there's no obvious way to do it, to me.

> I think the easiest (smallest impact on the spec) is to follow the 
> document tree. That requires no change to 10.1

Except that there are parts of 10.1 that already don't really follow the 
document tree, as I said in my earlier mail...  The containing block for 
a block inside a table row isn't the table row itself, right?

If we want to define containing blocks in terms of the document tree, 
then 10.1 needs a bunch more work to define which exact box, of the set 
of boxes generated by the ancestor element, is the containing block for 
various particular cases.

I know implementing in Gecko will be a lot simpler if the run-in just 
behaves like a child of the following block in terms of containing 
blocks; the other option means introducing a whole bunch of special code 
to do layout of run-ins and arbitrary descendants of run-ins 
specifically....  I can't speak to difficulty of implementation in other 
UAs (clearly none in IE, since they do it that way already; I'd be 
interested in feedback from Opera and Webkit).

> But I can also see that authors might expect the opposite, because the 
> run-in is visually part of the next paragraph. That would require some 
> major work on 10.1. Scary...

I think we need work on 10.1 in either case, sadly.  :(

-Boris

Received on Thursday, 3 September 2009 20:13:59 UTC