Re: [CSS21] Clarifications to run-in

On Thu, Sep 16, 2010 at 05:41:34PM -0700, fantasai wrote:

>   |  2. Let B be the first of A's in-flow following siblings. If B

Is the phrase "in-flow" defined in the editors' CSS2.1 text yet?  If not then
that would be an issue for the suggested replacement.  Also, note that the use
here pertains to elements and pseudo-elements rather than boxes, so either the
definition would need to include them or the wording changed.

>   |     exists and is a non-replaced block box, then A is rendered
>   |     as if it were an 'inline' element at the start of B's contents--
>   |     after B's list marker box, if any, and before B's ':before'
>   |     pseudo-element, if any. (See Chapter 12.)

The phrase "is rendered as if" is a bit unclear, but the obvious reading is I
believe not the behaviour we want.  For example, if A's (pseudo-element)
children reference counter c that is reset by B (and not reset by A), then I
believe the obvious reading of this text (in isolation at least) is that
counter string's rendering should be as if A were within the scope of that
counter reset, whereas in the existing text, A is clearly not within the scope
of the counter reset.  I believe we want A not to be within the scope of B's
counter reset, and I believe we want the rendering of A (including its
rendering of counter values) to reflect that.

Note also that marker boxes aren't elements or (in CSS2.1 at least)
pseudo-elements, so it doesn't make sense to say that A is rendered as if it
were an element after the marker box.

Thus, I suggest phrasing in terms of where A's box is placed in the box tree.
E.g. "generates an inline box at the start of B's principal box's children —
after ...".

(Also relevant to the suggestion of wording it in terms of box generation is
that 9.2.3 is a subsection of 9.2 "Controlling box generation".  Also, the fact
that we need the box tree to be defined, for example for zindex.html: without
the "rendering tree" in zindex.html being defined, all rendering of CSS
documents is pretty much undefined, so this is important; though I'm not sure
that "rendering tree" is actually synonymous with what www-style discussions
refer to as the "box tree".)


Regarding em dash representation: Existing practice within CSS2.1 consistently
uses spaces around em dashes [not counting the attribution ‘—GwieF’].
It sometimes uses ‘--’ and sometimes uses unicode em dash character ‘—’
(— / — / U+2014), though preferring unicode by a ratio of 11:3
(or by 4:1 if we include the ‘—GwieF’ case).  If using unicode em dash
character then using spaces around em dashes helps when rendered on character
grid media, such as in terminal windows or with Braille devices, because the
spacing facilitates distinguishing from hyphen or en dash.  (Even when
represented as ‘--’ on non-character-grid media, spacing gives a small
disambiguation benefit, in that ‘--’ is also sometimes used to represent en
dash.)  Using spacing is also beneficial for its effect on typed communication
at large, in that it reduces the frequency of people representing em dashes
with an unspaced simple hyphen character.  Spacing em dashes is also standard
typographical practice in some countries, including where I live.


> Replace
>    #   2. C has a computed value for 'display' of 'inline' and it has one
>    #      or more children that inhibit run-in behavior. (Where "children"
>    #      includes both normal elements and :before/:after pseudo-elements.)
> with
>    |   2. C is a non-replaced inline element and has one or more children
>    |      that inhibit run-in behavior.

"Inline element" is not a defined term, to my knowledge.  (For example, it
isn't mentioned in the proposal for issue 120 other than as text to be
removed from the spec.)  If it is defined as "an element that generates an
inline box", then the "non-replaced" qualifier is redundant (once issue 120's
proposal text is in the spec) and I believe is better removed.

(If we were to include a parenthetical note drawing attention to some aspect of
"inline box"'s definition, then more important would be the fact that an
inline-block/-table box is not an inline box.)


One possible issue concerns an interaction with a possible issue with the new
anonymous table object rules.  In every user agent supporting run-in that I've
tested, an element with display:table-row inhibits run-in.  However, note that
in each of these user agents, a display:table-row element that's a child of a
display:inline element causes a block-level anonymous table box to be generated
rather than an inline-table as both the existing 17.2.1 and its draft
replacement stipulate.  [Or at least, the table is placed on a line by itself
despite plenty of room.]  Gecko creates an inline-table, but of course doesn't
support run-in.

(The others that I tested were Konqueror, WebKit, and a 2005 version of Opera.
 I haven't tested any version of IE or Prince, and I haven't checked the most
 current version of any of them.)

I can see the specified behaviour as desirable, I'm just noting that a number
of implementations do otherwise, apparently interoperably among themselves.


pjrm.

Received on Tuesday, 21 September 2010 01:11:49 UTC