Re: [CSS21] 12.5 Lists: numbering undefined, implementations differ

On Tue, Sep 7, 2010 at 2:28 PM, Peter Moulder <peter.moulder@monash.edu> wrote:
> By "numbering" here, I mean the number as distinct from what string to display
> for a given number.
>
> As far as I've seen, there's no text saying what number to give for a given
> list-item.  The closest I've seen is an example of an <li> list in an HTML
> document; but note that that's an HTML list, whose numbering is [more or less]
> defined by the HTML spec, and so doesn't tell us much about how <span
> style="display:list-item"> should be numbered, or how list-items in generic XML
> documents should be numbered (when styled by CSS).

This actually appears to be underspecified in CSS 2.1.

The way all of this is supposed to work is that, in the browser
stylesheet, <ol> and <ul> have a "counter-reset:list-item" property,
and display:list-item causes the ::marker pseudo to be generated,
which uses the list-item counter and has "counter-increment:list-item"
on it.

These assumptions aren't actually documented, as you found.  Further,
there's nothing describing what the value of a counter should be when
it's used before a counter-reset has been applied to create a scope.

I think Gecko is the only one that actually pretends to do things as I
described above, and it looks like it just treats counters as always 0
if there isn't an appropriate scope for them (ignoring any
counter-increments that may occur).

All of this will be documented properly in CSS3 Lists.  Most of it
should already be.


> I append a document with a few tests, to see what existing user agents are doing.
> Of the four user agents I tested, no two do the same thing.
>
> In the implementations I looked at, it seems that in an HTML document, <ol> is
> special for display:list-item elements even other than <li>; and numbering of
> list-items that are descendents of an <ol> element had less variation in
> behaviour.
>
> (Looking at WebCore source code, it seems that the test is ol or ul.
> A reasonable starting point for the relevant code in WebKit would be
> RenderListItem::calcValue.)
>
> <ol> loses its magic in generic XML documents in each of the user agents
> whose generic XML behaviour I tested.
>
>
> Relevant to discussion would be http://www.w3.org/TR/css3-lists (search for
> counter; though the main point is that display:list-item implicitly increments
> a counter called list-item), and its dependency
> http://www.w3.org/TR/css3-content/ for most of the information regarding
> numbering.  Whether intentional or not, the numbering appears to be order
> within document tree, as modified by pseudo-elements such as :before and :after
> (by my reading, though it isn't very clear about this), and as modified by
> display:none, but not modified by run-in or 'caption-side' or anonymous block
> box processing; and as modified by the suppression of children of
> 'table-column' boxes and suppression of non-'table-column' children of
> 'table-column-group', but not modified by the rest of anonymous table object
> creation rules.  (Anonymous block processing and anonymous table object
> creation don't affect order of boxes/elements, but would be relevant to counter
> scope.)
>
> Note that both css3-lists and css3-content are at working-draft status.
>
> Possibly the resolution to this issue would be to note explicitly that CSS2.1
> does not define the number assigned to a given list-item, and that this is
> expected to be defined by a future level of CSS, probably making some mention
> of css3-lists (already in refs.html as #ref-CSS3LIST).

Right, this sounds like the right solution.  With everyone being
*completely* different, we pretty much just need to wait for a proper
spec to define this properly.  CSS3 Lists is the right place for this


> N.B. One of the tests caused a segfault in a WebKit-based browser; if that
> happens then comment out the :before rule in the stylesheet.

That doesn't seem to happen in more recent builds of Chrome, at least
(something other than the version pushed by autoupdate).

~TJ

Received on Tuesday, 7 September 2010 22:54:19 UTC