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

Re: [CSS21] display:run-in clarifications

From: Bert Bos <bert@w3.org>
Date: Thu, 3 Sep 2009 21:29:06 +0200
To: www-style@w3.org
Message-Id: <200909032129.06770.bert@w3.org>
On Thursday 03 September 2009, Boris Zbarsky wrote:

> So to sum up what I think is the current state of things as far as
> run-in goes.
> 1)  I think we should explicitly define that as far as conform.html
>      goes replaced elements have no children.

That's one of those things that are so obvious to me that it never even 
occurred to me that it could be ambiguous. :-) No problem making it 
clearer, of course. How about, under "Replaced element" in 3.1:

    [...] or applet. In the document tree[1], a replaced element is
    therefore represented as empty[2]. For example, [...]

[1] #doctree
[2] #empty

>      Once this is done, I 
>      believe we have a more or less complete definition of when
> run-ins run in; the remaining issue is generated content on replaced
> elements which I think we should either explicitly leave undefined
> (and say so) or define in some way that will automatically work
> sanely once the box generation for that case is defined.

At the moment I know of no way to define after/before on replaced 
elements in such a way that we can still refine it later. I'd rather 
keep it undefined. The note that currently says so ("This specification 
does not fully define the interaction of :before and :after with 
replaced elements") could be made normative.

(I think the reason that it is currently a note and not normative, is 
that what the note says can in principle be inferred already: the 
definition of before/after says the pseudo-elements behave as if they 
were children of the element, but the content of a replaced element 
isn't handled by CSS, hence that part of the definition doesn't 

> 2)  Need to 
> figure out what should be happening with containing blocks for
> descendants of the run-in; that includes all descendants that do
> something with the 'width' property (absolutely positioned, floated,
> inline-block, inline-table, replaced element).

I think the easiest (smallest impact on the spec) is to follow the 
document tree. That requires no change to 10.1 and just a clarification 
in 9.2.3. E.g., just after the paragraph that starts "Despite..." 
insert a paragraph similar to this: "Similarly, the following block box 
does not establish a containing block for the run-in element or its 

But I can also see that authors might expect the opposite, because the 
run-in is visually part of the next paragraph. That would require some 
major work on 10.1. Scary...

> 3)  Need to figure out 
> how inheritance works, and in particular how it works when run-in
> interacts with first-line and first-letter.

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Thursday, 3 September 2009 19:29:50 UTC

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