W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: [CSS21] display:run-in clarifications

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 01 Sep 2009 15:55:48 -0400
Message-ID: <4A9D7C44.4070705@mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style@w3.org
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.

> In the ::first-line case, you want the run-in to inherit only from its
> parent rather than the ::first-line child of the following block.

This is a tough one; I could go either way here, actually.  Note that 
inheritance inside first-line is generally broken in the spec already, 
of course.

> This implies that either the run-in is treated as a sibling of the
> following block

Which it is in the non-first-line case for purposes of inheritance, 
right?  At least in UAs that implement run-in.

> However, in the ::first-letter case you want the ::first-letter to
> apply to the run-in.  This seems to imply that the run-in is treated
> as a normal child of the following block and generated pseudo-children
> of the following-block can appear in/before it.

Generated content for the following block (:before, to be exact) comes 
after the run-in.

:first-letter is nested inside the deepest first child, so it would come 
_inside_ the run-in.

Generally, it seems to me that run-in is supposed to work just like an 
inline placed inside the block before everything else (including the 
:before content).

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.

If the run-in were to inherit style from the block it runs into, then 
you immediately run into issues similar to the ones first-line has:

   <div style="display: run-in">
     <div style="display: inherit">Does this run in?</div>
     <div style="display: block"></div>

> What rule are you using to make these decisions?

Some combination of implementation expediency (though none of these 
inheritance issues are particularly deal-breakers for implementing in 
Gecko, really; some are just easier than others) and just trying to 
reconcile several parts of the spec that all make sense individually but 
not so much when put together.  Hence the need for clarifications.

Received on Tuesday, 1 September 2009 20:08:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC