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 12:33:55 -0400
Message-ID: <4A9D4CF3.7090503@mit.edu>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org
Bert Bos wrote:
>> Since this is all being defined on _elements_, not boxes, the
>> <object> in fact has a display:block child and so would inhibit its
>> parent from being run in per the existing rule c, even if the
>> <object> is display:inline.  That seems wrong to me...
> If the OBJECT has a child then it is not replaced, and conversely when 
> it is replaced it has no child.

Sorry, that's the case for the _box_ tree, but not the DOM tree.  The 
definition we're working with here is done on the DOM tree (or at least 
that's where all the reference links point to); in the DOM the <object> 
always has children.

> In this case the author used DIV as fallback, not SPAN, which rather 
> suggests that he wants the fallback to be a paragraph or more. That 
> doesn't seem wrong at all. Especially as he also had the option to 
> use 'inline-block'. Clearly, he wants the OBJECT to be inline *only* 
> when it is actually replaced, not when the fallback text is displayed 
> instead.

I'm talking about the case when the <object>'s fallback is not shown. 
When its fallback is shown there's no problem here.

> On the other hand, what to do with :before/:after on replaced elements 
> is trickier. It's not for nothing that the WG decided to postpone the 
> issue. :-)


> We need to define it for CSS3, but I'd rather not hold up CSS 2.1. Maybe 
> somebody finds *the* solution and we all agree immediately, but it 
> rather looks like it will be a long and complex definition with lots of 
> if-then clauses...

The other option, as I said, is defining run-in in terms of the box 
tree, not the element tree.  Then the definition will simply work 
however it should once we sort out what boxes, if any, :before and 
:after on replaced elements should generate.

Received on Tuesday, 1 September 2009 16:34:38 UTC

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