- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 01 Sep 2009 12:33:55 -0400
- 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. :-) Agreed. > 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. -Boris
Received on Tuesday, 1 September 2009 16:34:38 UTC