- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 01 Sep 2009 15:55:48 -0400
- 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> </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. -Boris
Received on Tuesday, 1 September 2009 20:08:59 UTC