- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Thu, 02 Sep 2010 21:32:01 +1000
- To: "www-style@w3.org list" <www-style@w3.org>
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