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

Re: [CSS21] display:run-in clarifications

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 26 Aug 2009 21:21:41 -0700
Message-ID: <4A9609D5.6070303@mit.edu>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org
Bert Bos wrote:
> A run-in element A behaves as follows:
> 
>    1. If A has any children[1] that inhibit run-in behavior (see below),
>       or if it has any :before or :after pseudo-elements[4] that inhibit
>       run-in behavior, then A is rendered as if it had 'display: block'.
> 
>    2. Let B be the first of A's following siblings[2] that is neither
>       floating nor absolutely positioned[3] nor has 'display: none'. If
>       B exists and has a specified value for 'display' of 'block'
>       or 'list-item', then A is rendered as an 'inline' element at the
>       start of B's principal box[5]. Note: A is rendered before
>       B's ':before' pseudo-element, if any. See 12.1[4].
> 
>    3. Otherwise, A is rendered as if it had 'display: block'.

Bert, thank you for writing this up and testing the behavior in various 
browsers!

These seem pretty reasonable to me, with two caveats.

1)  If in rule 2 B and A are expected to be elements, then this case:

CSS:

   #parent::after { display: block; content: "after"; }
   #parent > div { display: run-in; }
   #parent { display: block; }

HTML:

   <div><div>Does this run in?</div></div>

won't run the child div into the ::after anonymous element.  Should it? 
  If so, it might be worth explicitly calling that out (e.g. by saying 
that B might be an ::after pseudo-element), given that we call that out 
explicitly elsewhere in the algorithm.

2)  In rule 2, B needs to be non-replaced in addition to the other 
conditions on it.

> [Definition:] An element or pseudo-element C inhibits run-in behavior if 
> one or more of the following are true. (Note that the definition is 
> recursive.)
> 
>    a. C is not floating and not absolutely positioned[3] and the
>       specified value of its 'display' is one of 'block', 'list-item'
>       or 'table'.
> 
>    b. C is not floating and not absolutely positioned[3] and it has one
>       or more children that inhibit run-in behavior.
> 
>    c. C is not floating and not absolutely positioned[3] and it has
>       a :before pseudo element[4] that inhibits run-in behavior.
> 
>    d. C is not floating and not absolutely positioned[3] and it has
>       an :after pseudo element[4] that inhibits run-in behavior.

This doesn't seem quite right to me.  In particular, the interaction of 
rules a and b is such that in this situation:

   <div style="display:run-in">
     <div style="display: table-cell">
     </div>
   </div>
   <div style="display: block"></div>

the run-in will run in, but in this situation:

   <div style="display:run-in">
     <div style="display: table-cell">
       <div style="display: block"></div>
     </div>
   </div>
   <div style="display: block"></div>

it won't.  Indeed, the display:table-cell child doesn't inhibit run-in 
behavior on its own, per rule a, but does in the second case because of 
its own block child because of rule b.  Similar issues arise if C has 
display:inline-block or display:inline-table or whatnot.

It might be that this is the behavior we want, but an alternative is 
adding "and the specified value of its display is 'inline'" to 
conditions b,c,d above.  And possibly that C is non-replaced, for 
conditions b,c,d; if we have a replaced element which happens to have a 
DOM child (which is what our definition of children is here) that has 
specified "display:block", that should have no effect on the parent 
run-in, I would think.  Personally, I would prever this approach.

-Boris
Received on Thursday, 27 August 2009 04:22:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:20 GMT