Re: Action Item for Issue 198

On Mon, Aug 23, 2010 at 05:50:37AM -0700, Stephen Zilles wrote:
> The issue is to clarify the behavior of Run-ins and Floats.
> 
> EXISTING GROUP DRAFT TEXT
> 9.2.3 Run-in boxes
> 
> A run-in element (or pseudo-element) A behaves as follows:
> 
>  1.  If A has any
>  children<http://www.w3.org/Style/Group/css2-src/conform.html#child> that
>  inhibit run-in
>  behavior<http://www.w3.org/Style/Group/css2-src/visuren.html#inhibit-run-in>
>  (see below), then A is rendered as if it had 'display: block'.

The publicly-visible http://www.w3.org/TR/CSS21/visuren.html doesn't have a
#inhibit-run-in anchor (or any occurrence of `inhibit'), so it would be helpful
to post that text here.

>  2.  Let B be the first of A's following
>  siblings<http://www.w3.org/Style/Group/css2-src/conform.html#sibling> that
>  is neither floating nor absolutely
>  positioned<http://www.w3.org/Style/Group/css2-src/visuren.html#absolutely-positioned>
>  nor has 'display: none'. If B exists and has a specified value for 'display'
>  of 'block' or 'list-item' and is not
>  replaced,<http://www.w3.org/Style/Group/css2-src/conform.html#replaced-element>
>  then A is rendered as an 'inline' element at the start of B's principal
>  box.<http://www.w3.org/Style/Group/css2-src/visuren.html#principal-box>
>  Note: A is rendered before B's ':before' pseudo-element, if any. See
>  12.1.<http://www.w3.org/Style/Group/css2-src/generate.html#before-after-content>

Thank you for being explicit about the interaction with :before.

It would also good to be explicit about the interaction with
list-style-position:inside, which has what appears to be a conflict:

  | A is rendered as an 'inline' element at the start of B's principal box.

versus:

  # The marker box is the first inline box in the principal block box

One would tend to take "rendered ... at the start of" to mean "as the first
inline box in B's principal box", which would give a conflict as to whether the
run-in or the marker box is the first inline box of B's principal box.

Given the appearance for list-style-position:outside (where the run-in appears
to follow the marker box), I suppose the behaviour we'd want is for the run-in
box to follow any list-style-position:inside marker box of B.

In any case, I suggest using more precise wording than "rendered at the start
of": "at the start of" is vague (both for the position of the run-in box and
for how it affects the positions of other boxes), and "rendered" is arguably
incorrect in some cases.  I suggest instead "generates an inline box", and then
some statements about the position of that box in the box tree.

The other text I can think of that could have interactions with this text would
be the rules for anonymous block boxes (section 9.2.1.1).  Presumably the
#inhibit-run-in text deals with most of this, though it's also relevant to the
wording describing where the box goes in the box tree.

I can't think of any interaction with the anonymous table object stuff except
an interaction that mostly concerns section 9.2.1.1 and/or #inhibit-run-in
text, namely the question of what to do when the run-in element contains an
inline element that contains a table-row-group element: whether its anonymous
table box should be 'inline-table' or 'table'.  (I'd tend to expect 'inline-table',
but some implementations seem to go with 'table'.)

>  3.  ...
> Suggested NOTE: Above, A refers to the entire content of the run-in element,
> including floats. When A is rendered inside B,

Again, I would prefer to avoid phrase "rendered inside B", which is presumably
not quite what's intended in cases involving e.g. position:relative or
visibility:hidden.  Perhaps "runs in" or "generates an inline box".

> any siblings of A and B that lie between them are consider to precede A for
> the purpose of rendering; for example, any float C that follows A and
> precedes B in the source tree will be considered to precede A for the
> purposes of 'clear".

The above is not entirely clear as to whether it's talking about position in
element tree (as suggested by "precede A", given that A is an element rather
than a box) or the box tree (as suggested by mentions of rendering and possibly
'clear', depending on how that ends up getting defined once we've made the
change from element to box in most places in the spec; and also, again
depending on how the element/box changes result in, it might seem superfluous
to make this note if we were talking about the element tree, given that C
already precedes B in the element tree, and C's placeholder box would already
precede A's box).

I'll grant that the unclarity may well disappear once the element/box changes
have been made to sections 8.3.1 and 9.5.2, but in the meantime I'd
nevertheless suggest making explicit mention of boxes or elements in this note.

Currently, sections 8.3.1 and 9.5.2 use a mix of "element" and "box" language.
For example, the 'clear' property says both "earlier floating box" (which by
itself would most likely be judged in terms of the box tree) but then later
says "boxes that resulted from elements earlier in the source document".  My
impression from cursorily following issues 159 and 198 is that both 8.3.1 and
9.5.2 are to be changed to be in terms of order in box tree rather than element
tree; in which case it should suffice to make statements about order of boxes
in the box tree.

Again, I'd also suggest avoiding the unclear phrase "considered for rendering
purposes", and instead make a concrete statement about the box tree, and/or
clarifying whatever sections are intended to be covered by "for rendering
purposes".

pjrm.

Received on Thursday, 2 September 2010 11:32:32 UTC