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

Re: [CSS21] Clarifications to run-in

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 17 Sep 2010 14:16:38 -0400
Message-ID: <4C93B086.4010301@mit.edu>
To: fantasai <fantasai.lists@inkedblade.net>
CC: "www-style@w3.org" <www-style@w3.org>
On 9/16/10 8:41 PM, fantasai wrote:
> It's painfully explicit about certain things that should be specified
> clearly in a general sense, and not called out specifically here.

Yes, but that was a consequence of it being defined on the _element_ 
tree, not the formatting structure, right?  My initial proposal, which 
was defined on a conceptual tree of boxes, was much simpler.  But there 
was some insistence at the time on defining this purely on the element 
tree, so here we are.

> Calling them out here implies that there are ambiguities everywhere
> they are not mentioned.

Well.... aren't there?  But see below.

> 1. The most obvious one here is the distinction between elements and
> pseudo-elements, which was recently clarified in 5.12.

Link, please?  I can't locate the editor's draft in my bookmarks at the 
moment.  (It'd be awful nice if the issue document linked to diff or at 
least the current editor's draft.)

> 2. The other is the mention of ignoring "display: none" elements,
> which are already specified to be taken out of the formatting tree.

Yes, but this algorithm is working on the element tree, not on the 
formatting structure (which isn't a tree per Bert, etc).

> (If that's not clear enough generally

It's clear that display:none elements are not present in the formatting 
structure.  The algorithm under discussion does not operate on the 
formatting structure......

> because not ignoring them would
> break most of the formatting algorithms in the spec: table layout,
> margin collapsing, etc.)

Those operate on the formatting structure, so don't have any issues like 
this.

> # 2. Let B be the first of A's following siblings that is neither
> # floating nor absolutely positioned nor has 'display: none'.
> # If B exists and has a specified value for 'display' of 'block'
> # or 'list-item' and is not replaced, then A is rendered as an
> # 'inline' element at the start of B's principal box. Note: A
> # is rendered before B's ':before' pseudo-element, if any.
> # See 12.1.
> with
> | 2. Let B be the first of A's in-flow following siblings. If B
> | exists and is a non-replaced block box, then A is rendered
> | as if it were an 'inline' element at the start of B's contents--
> | after B's list marker box, if any, and before B's ':before'
> | pseudo-element, if any. (See Chapter 12.)

That's not equivalent at all.  For example, a caption is a non-replaced 
block box, right?  But we do NOT want the run-in running in in this 
situation, I would think:

   <span style="display: run-in">I am a run-in</span>
   <span style="display: table-caption">Keep away from me</span>

So you do need the explicit "display:block/list-item" check here, I 
think.  You also need the "display:none" check unless you rewrite this 
whole section to work on the formatting model.  I'm fine with the 
changes to the last sentence to make the :before behavior normative and 
clarify the behavior wrt markers.

> Remove
> # In the above, "siblings" and "children" include both normal elements
> # and :before/:after pseudo-elements.

I'd need to see the exact language added to 5.12 to tell you whether 
this is ok.

> To generalize the last rule to work with new CSS3 display types, replace
> # 1. C is not floating and not absolutely positioned and the computed
> # value of its 'display' is one of 'block', 'list-item', 'table'
> # or 'run-in'.
> with
> | 1. C generates an in-flow block-level box or has a computed 'display'
> | value of 'run-in'.

I'd have to see the new block-level-box generation stuff to make sure, 
but this doesn't give the same behavior.  In particular, this markup:

   <span style="display: run-in">
     <span>
       <span style="display: table-caption"></span>
     </span>
     Do I run in?
   </span>
   <div>
     Run into me!
   </div>

runs in with the old text but not with your new text.

> Replace
> # 2. C has a computed value for 'display' of 'inline' and it has one
> # or more children that inhibit run-in behavior. (Where "children"
> # includes both normal elements and :before/:after pseudo-elements.)
> with
> | 2. C is a non-replaced inline element and has one or more children
> | that inhibit run-in behavior.

This part I'm happy with.

-Boris
Received on Friday, 17 September 2010 18:17:13 GMT

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