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

On Fri, Dec 2, 2011 at 10:37 AM, L. David Baron <dbaron@dbaron.org> wrote:
> 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.

This is needed to properly implement <li value> in CSS, right?


>> > 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.)

Hm, I guess I'm going to have to go look up that feedback.


>> 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.

Yeah.

~TJ

Received on Friday, 2 December 2011 18:50:49 UTC