Attempt at summary of run-in

(The CSS WG wanted me to prepare next week's discussion on 'run-in'. 
After I submitted the questions below for the agenda, somebody thought 
the message was a useful summary on its own. So here it is.)


----------  Forwarded Message  ----------

Boris Zbarsky raised an issue about the exact rendering of 'display: 
run-in'. That issue has several aspects:



1) When does the element run in and when does it fall back to being a 
block?

STATUS: The old text expressed a clear intention, but wasn't precise 
enough. There is a proposal for concrete text for CSS 2.1 section 9.2.3 
that seems to both remove the ambiguities and express what people want 
to happen:

    http://lists.w3.org/Archives/Public/www-style/2009Aug/0607.html

with the definition replaced by

    http://lists.w3.org/Archives/Public/www-style/2009Sep/0013.html

SUGGESTED ACTION: Accept this text.



2) The definition above doesn't explicitly call out replaced elements, 
because for the purposes of this definition they behave like any other 
empty element... except that it is possible to interpret section 3.1 in 
such a way that replaced elements need *not* be empty.

The spec says literally that the content of replaced elements 
is "outside the scope." The intention is that the content is outside 
the document tree. That intention could be made explicit.

STATUS: There is a proposed addition to section 3.1:

   http://lists.w3.org/Archives/Public/www-style/2009Sep/0064.html

Both Boris and I think it is adequate.

SUGGESTED ACTION: Accept this text.



3) What is the containing block of the run-in and its children?

Following the definition in 10.1, the containing block is found purely 
by following parent links in the document tree. Which implies that the 
paragraph that a header runs into is never the containing block for the 
run-in or its children, because it isn't an ancestor. But visually 
it "contains" the run-in, so that may be unexpected for authors.

STATUS: There seems to be no preferred solution yet: follow the document 
tree, the same way property inheritance works; or follow the visual, 
the same way line box construction works.

It seems IE does the latter currently and Gecko could do it easily. No 
other data is available yet about ease of implementation or users' 
expectations.

SUGGESTED ACTION: We need to decide.



4) I said above that 10.1 defines a behavior, but Boris thinks it is 
actually ambiguous. It uses the phrase "ancestor box," which I take to 
mean the "ancestor's box" but Boris thinks it can mean the box that is 
an ancestor in the "formatting structure." (Chapter 2 says that the 
structure of the "formatting structure" is not defined and that it need 
not be a tree, but if you believe that it *is* a tree, you can easily 
read "parent box" and "ancestor box" as being distinct from "parent's 
box" and "ancestor's box.")

STATUS: It's not yet clear how serious this ambiguity is. There are no 
proposals for removing it.

SUGGESTED ACTION: Decide if we want to review the occurrences 
of "ancestor box" and similar terms and suggest rewrites.



5) What properties apply to a run-in that is also a ':first-line'?

That the first-line pseudo-elements of the heading's ancestors are taken 
into account for the style of the run-in seems clear, but what about 
the fist-line pseudo-element of the sibling paragraph? We could even 
define that some properties apply but others not... (It may be that 
Webkit indeed inherits different properties differently, but given that 
there is already different behavior in different implementations of 
first-line even without run-in, it is hard to say.)

STATUS: Three options, A, B and C, are defined (but without concrete 
text) in:

    http://lists.w3.org/Archives/Public/www-style/2009Sep/0043.html

and Boris suggests that Webkit might be implementing a fourth option, 
called B':

    http://lists.w3.org/Archives/Public/www-style/2009Sep/0049.html

in which the run-in heading also inherits from the paragraph, but only 
if the paragraph has a first-line pseudo-element.

It is difficult to get any intuition for what *should* happen, because 
you typically only use one or the other.

Tab thought there might be a way to avoid taking a decision, viz., by 
designing an alternative way to style the run-in. If, e.g., there were 
a '::run-in' pseudo-element (in CSS3), then ':first-line' need not 
apply to the run-in part, because designers can decide by themselves if 
the run-in gets the style of the first-line or not.

SUGGESTED ACTION: Discuss...

-------------------------------------------------------



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, 10 September 2009 19:49:14 UTC