Bugzilla

Simplified testcase:

    data:text/html,<ol><li>one<li>two<li style="counter-reset:list-item 10">three<li>four

This renders in Firefox as:

     1. one
     2. two
    11. three
     3. four

which seems surprising at first glance. However, I think this is correct behavior per [CSS List and Counters](https://drafts.csswg.org/css-lists-3/#counter-reset), because `counter-reset` does not simply change the value of a counter; as the spec says:

> The counter-reset property instantiates new counters on an element and sets them to the specified integer values.

So in this example, a *new* list-item counter is instantiated on the third `<li>` element; but then at the end of that element, it goes out of scope and the fourth `<li>` continues to use the outer counter that was not touched.

In practice, I think this means that `counter-reset` is rarely useful in the middle of a sequence like this (whereas `counter-set` and `counter-increment`, which [manipulate the value of existing counters](https://drafts.csswg.org/css-lists-3/#increment-set), are more likely to do what an author would expect here).

(Observe that if `counter-reset` is used on the *parent* of all the `<li>` elements, the result is just what you'd expect:

    data:text/html,<ol style="counter-reset:list-item 10"><li>one<li>two<li>three<li>four

renders as:

    11. one
    12. two
    13. three
    14. four

because all the items use the counter that was instantiated on the enclosing `<ol>`.)

The MDN page could do with a better explanation of this property, I think, as it doesn't seem to mention that `counter-reset` *instantiates new counters* and the resulting scoping implications.

Simplified testcase:

    data:text/html,<ol><li>one<li>two<li style="counter-reset:list-item 10">three<li>four

This renders in Firefox as:

     1. one
     2. two
    11. three
     3. four

which seems surprising at first glance. However, I think this is correct behavior per [CSS List and Counters](https://drafts.csswg.org/css-lists-3/#counter-reset), because `counter-reset` does not simply change the value of a counter; as the spec says:

> The counter-reset property instantiates new counters on an element and sets them to the specified integer values.

So in this example, a *new* list-item counter is instantiated on the third `<li>` element; but then at the end of that element, it goes out of scope and the fourth `<li>` continues to use the outer counter that was not touched.

In practice, I think this means that `counter-reset` is rarely useful in the middle of a sequence like this (whereas `counter-set` and `counter-increment`, which [manipulate the value of existing counters](https://drafts.csswg.org/css-lists-3/#increment-set), are more likely to do what an author would expect here).

(Observe that if `counter-reset` is used on the *parent* of all the `<li>` elements, the result is just what you'd expect:

    data:text/html,<ol style="counter-reset:list-item 10"><li>one<li>two<li>three<li>four

renders as:

    11. one
    12. two
    13. three
    14. four

because all the items use the counter that was instantiated on the enclosing `<ol>`.)

The MDN page could do with a better explanation of this property, I think, as it doesn't seem to mention that `counter-reset` *instantiates new counters* and the resulting scoping implications. Filed https://github.com/mdn/content/issues/6360 about this.

Simplified testcase:

    data:text/html,<ol><li>one<li>two<li style="counter-reset:list-item 10">three<li>four

This renders in Firefox as:

     1. one
     2. two
    11. three
     3. four

which seems surprising at first glance. However, I think this is correct behavior per [CSS List and Counters](https://drafts.csswg.org/css-lists-3/#counter-reset), because `counter-reset` does not simply change the value of a counter; as the spec says:

> The counter-reset property instantiates new counters on an element and sets them to the specified integer values.

So in this example, a *new* list-item counter is instantiated on the third `<li>` element; but then at the end of that element, it goes out of scope and the fourth `<li>` continues to use the outer counter that was not touched.
[edit: I believe this is wrong; the fourth item *should* inherit the scope of its preceding sibling; see comment 6.]

In practice, I think this means that `counter-reset` is rarely useful in the middle of a sequence like this (whereas `counter-set` and `counter-increment`, which [manipulate the value of existing counters](https://drafts.csswg.org/css-lists-3/#increment-set), are more likely to do what an author would expect here).

(Observe that if `counter-reset` is used on the *parent* of all the `<li>` elements, the result is just what you'd expect:

    data:text/html,<ol style="counter-reset:list-item 10"><li>one<li>two<li>three<li>four

renders as:

    11. one
    12. two
    13. three
    14. four

because all the items use the counter that was instantiated on the enclosing `<ol>`.)

The MDN page could do with a better explanation of this property, I think, as it doesn't seem to mention that `counter-reset` *instantiates new counters* and the resulting scoping implications. Filed https://github.com/mdn/content/issues/6360 about this.