- From: Bert Bos <bert@w3.org>
- Date: Thu, 3 Sep 2009 21:29:06 +0200
- To: www-style@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
apply...)
> 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
descendants.
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
--
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