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

Re: [CSS21] display:run-in clarifications

From: Bert Bos <bert@w3.org>
Date: Tue, 1 Sep 2009 18:12:00 +0200
To: www-style@w3.org
Message-Id: <200909011812.01037.bert@w3.org>
On Monday 31 August 2009, Boris Zbarsky wrote:
> Bert Bos wrote:

> Doesn't look like that to me.  Consider the following HTML markup:
>
>    <object>
>      <div>Some fallback content</div>
>    </object>
>
> 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. Currently, CSS doesn't define or 
control when an OBJECT is a replaced element. It assumes an oracle that 
knows the nature of the element.

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.

>
> > The added condition is "inline or run-in" instead of just "inline"
>
> Oh, good catch.
>
> Though this brings up another issue.  A "display:run-in" child should
> inhibit run-in behavior in all cases (so should be added to part (a)
> here).  Indeed, either it doesn't run in (and then is a block and
> should inhibit run-in behavior) or it does run in (and then is
> followed by a block or list-item which would inhibit run-in behavior
> anyway).
[...]
> I like this, if we add 'run-in' to the list in part (a) and deal with
> the replaced element issue....

Agreed.

I was thinking that a run-in inside a run-in would be somehow ignored, 
because it was part of a run-in already. But that is indeed not 
consistent and would need additional rules. So that last definition 
then becomes:

---------------------------------------------------------------------------
[Definition:] An element or pseudo-element C inhibits run-in behavior if 
one of the following is true. (Note that the definition is 
recursive.)

   a. C is not floating and not absolutely positioned[3] and the
      computed value of its 'display' is one of 'block', 'list-item',
      'table', or 'run-in'.

   b. 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.)
---------------------------------------------------------------------------

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...

Just to give some examples, I'd like both of the following to 
automatically set the height in proportion to the width:

    img {width: 6em}

    p:before {content: url(foo.png); width: 6em}

but I'm not sure what I want 'width' to do in the following two...

    img:before {content: attr(title) "-"}
    img {width: 6em}

    p:before {content: "[" url(foo.png) "]"; width: 6em}



Bert
-- 
  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 Tuesday, 1 September 2009 16:12:41 GMT

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