Re: [css3-lists] counter-reset and counter-increment

On Friday 2011-12-02 10:25 -0800, Tab Atkins Jr. wrote:
> On Fri, Dec 2, 2011 at 10:17 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> > Hi,
> >
> > The counter-reset and counter-increment properties are not defined in Lists
> > and Counters Level 3, while they are mentioned in the prose (in section 2)
> > and used in examples.
> >
> > They are defined in CSS3 Content, but that spec is marked as obsolete and
> > the definition seems to be the same as in CSS 2.1. Lists 3 should explicitly
> > link to either 2.1 or Content 3 for defining these properties.
> 
> Yeah, I was thinking that I should probably define them in Lists.
> I'll see about doing so today.

We should probably also add a mechanism (maybe a 'counter-set'
property) that assigns the value of a counter without creating a new
scope.  We keep needing this.

-David

> > Also, section 12.5.1 of CSS 2.1 reads:
> >
> > """
> > CSS 2.1 does not define how the list numbering is reset and incremented.
> > This is expected to be defined in the CSS List Module [CSS3LIST].
> > """
> >
> > Lists 3 defines that lists are based on the list-item counter, and that
> > `display: list-item` increments that counter. However there is nothing
> > normative about resetting this counter. Only the sample stylesheet suggests
> > that or and ul elements reset the list-item counter.
> >
> > Does this mean that the counter is not reset anywhere else unless author or
> > user stylesheets have a counter-reset rule? I’m thinking of lists made
> > without ul/ol/li elements but with `display: list-item`.
> 
> The following line from Content should apply: "If ‘counter-increment’
> refers to a counter that is not in the scope (see below) of any
> ‘counter-reset’, the counter is assumed to have been reset to 0 by the
> root element.".
> 
> I don't believe this is actually what browsers do, though.  WebKit, at
> least, has something more complex; I think we might be assuming that
> the parent element resets the counter to 0, rather than the root.
> I'll need to do some testing to figure out exactly what should be
> specified.

Yes, that's incorrect, and I recall agreeing to change it.  It's
possible that the full set of counter-related errata that were
supposed to get into 2.1 didn't make it in.  We agreed on a whole
bunch of changes at one point (around when I was implementing
counters in early 2005).

(That particular rule violates incremental rendering, since it
requires renumbering all prior uses of counters() with that name to
have an extra "0." at the start.)

> In any case, something like the above applies - counters that have
> never been explicitly reset are still implicitly reset in some way.

Yes, but not at the root.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Friday, 2 December 2011 18:38:26 UTC