Re: [CSS21] display:run-in clarifications

On Tue, Sep 1, 2009 at 2:55 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>> In the positioning case, you want an abspos child of the run-in to
>> treat the following block (that the run-in ran into) as a positioning
>> ancestor.  This implies that the run-in is treated as a child of the
>> following block for CSS purposes.
>
> What I want is to determine containing blocks purely on the box tree,
> without reference to the content tree.

Ok; I agree with you that this is reasonable.  To be anywhere near
consistent, though, *inheritance* has to still operate *purely* on the
DOM tree, to avoid the contradiction issues you mentioned.  After
everybody's gotten their values sent down the chain, then we can base
things like containing blocks off of the box tree.

I'm still not 100% up on exactly what the various levels of value
mean, and at which level things get locked in.  Is this sort of thing
possible?

> I'm having a hard time reconciling all that with the observed behavior where
> the run-in doesn't normally inherit style from the block.  On the other
> hand, this behavior makes perfect sense when one thinks about first
> computing all styles and _then_ munging the box tree to handle run-ins.
>  Note that by the time the run-in ends up inside the block its style has
> already been computed in this model.

Yeah, just let things inherit from the DOM, *then* act on the box tree
for stuff like containing blocks.

At what point are the ::first-line and ::first-letter pseudoelements
created?  Would it be after inheritance (basically causing a second
round of inheritance cascade) or before?  If the former, they'll act
on the run-in.  If the latter, they won't (as the run-in won't be part
of the block they apply to yet).

~TJ

Received on Tuesday, 1 September 2009 21:35:33 UTC