1718070 - I believe there is a bug on this page: https://developer.mozilla.org/en-US/docs/Web/CSS/counter-reset

Status: RESOLVED DUPLICATE of bug 1717772

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Description

[jenniferadenicolo]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36

Steps to reproduce:

I believe there is a bug on this page: https://developer.mozilla.org/en-US/docs/Web/CSS/counter-reset

In counter-reset: chapter-count 5; the demo shows the second item numbered 6 as it should. I am aware that what shows will be one higher. 0 in the declaration = 1 in the list.

In all other browsers the following items are then also incremented to show 7 and 8, which I believe is correct.

In Firefox the following list items remain as the were.

Actual results:

Multiple lists with auto-numbering are displaying incorrectly.

First List

1. Item A
2. Item B

Second List

1. Item A
2. Item B

Third List

1. Item A
2. Item B
3. Item C

Expected results:

Lists should use proper numbering.

Multiple lists with auto-numbering are displaying incorrectly.

First List

1. Item A
2. Item B

Second List

1. Item A
2. Item B

Third List

1. Item A
2. Item B
3. Item C

Comment 1

[Jonathan Kew [:jfkthame]]

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

Comment 2

[vikash.ckiiita30]

This has changed only recently, I have tested with version 80.0 and it is continuing the numbering after reset. So in example

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

It will render it as

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

Similarly the counter reset example(https://developer.mozilla.org/en-US/docs/Web/CSS/counter-reset) on MDN is behaving differently in version 80.0 and 89.0

If you open this example and select fourth option counter-reset: chapter-count 5; then in version 80.0 it will display numbers as

Chapter 1: Down the Rabbit-Hole
Chapter 6: The Pool of Tears
Chapter 7: A Caucus-Race and a Long Tale
Chapter 8: The Rabbit Sends in a Little Bill

but in version 89.0.x it will render it as

Chapter 1: Down the Rabbit-Hole
Chapter 6: The Pool of Tears
Chapter 2: A Caucus-Race and a Long Tale
Chapter 3: The Rabbit Sends in a Little Bill

So I believe there is some recent change with respect to this behavior, also we same behavior, as in version 80.0, in chrome and edge as well.

Comment 3

[Jonathan Kew [:jfkthame]]

The behavior changed in bug 1548753 (Firefox 82). My understanding is that the new behavior more accurately follows the spec, but Mats knows this better and can probably confirm.

To get a result like

Chapter 1: Down the Rabbit-Hole
Chapter 6: The Pool of Tears
Chapter 7: A Caucus-Race and a Long Tale
Chapter 8: The Rabbit Sends in a Little Bill

I think the proper solution would be to use counter-set: 6 on the second item, not counter-reset.

Comment 4

[PeterG.UK]

In the post above reference is made to Bug 1548753. In that bug there is a comment about seeing what Chrome does.

Both Chrome and Edge work on the basis that if the second item is reset to say 6, the next item will be 7 and so on. This is affecting all help files produced by Adobe RoboHelp where Firefox has always worked as posted.

Comment 5

[Jonathan Kew [:jfkthame]]

I hope Mats will take a look and confirm what is correct here (note that Mozilla is largely closed this week, however, so responses may be slow). But I'll also note that Chrome's implementation of counter scoping/instantiation appears to be buggy, so is probably not a good guide to expectations; e.g. taking "example 19" from https://drafts.csswg.org/css-lists/#list-item-counter (with a small bug-fix because the "Third second-level item" is misplaced; I'll file an issue against the spec), Chrome ends up prefixing all items after the first with a spurious extra "1.", suggesting that it has instantiated a new counter scope where none was expected (see https://codepen.io/jfkthame/pen/qBmBeaV).

Not sure any browser handles this stuff entirely correctly... :-(

Comment 6

[Jonathan Kew [:jfkthame]]

On looking at this again, I'm beginning to think the Firefox behavior here does not conform to the spec (as I suggested in comment 3), because counter scope is supposed to be inherited not only from an element's ancestors but also from preceding siblings. The patch in bug 1548753 is titled "prefer an ancestor's counter scope over a sibling's scope", which is exactly what causes the problem here; the sibling's scope is what is wanted, and we're now ignoring it in favor of the ancestor.

The discussion of (potentially broken) uses of list markup in bug 1548753 gives the background as to why this was done, but I wonder if we need to reconsider that in some way given the impact it's having here. For a further example, see https://codepen.io/jfkthame/pen/mdmyJdN which is closely based on "Example 22" from the spec; current Firefox does not number the sub-headings under Heading B correctly.

Mats, Emilio: any thoughts on how we should proceed here? It seems this is.... complicated.

Comment 7

[Mats Palmgren (inactive)]

the sibling's scope is what is wanted, and we're now ignoring it in favor of the ancestor.

No, we want the scope on the nearest ancestor element. That's what is in the spec, in particular:

For each counter of sibling counters, if element counters does not already contain a counter with the same name, append a copy of counter to element counters.

(my emphasis)
Note that the parent element's counter set is added in step 2, before the sibling counters.

We render that MDN example correctly per spec, Chrome doesn't. (See bug 1717772 for details.)

However, the example is poorly marked up, so it triggers an edge case where Chrome has a bug currently.
(There's an MDN github issue about updating the example with proper markup.)

Not sure any browser handles this stuff entirely correctly... :-(

As far as I know, we implement the spec for CSS counters correctly.

FYI, Chromium/WebKit is extremely buggy when it comes to the built-in list-item counter (which it handles differently from other counters it seems).
They fail on even the simplest of examples: https://bugs.chromium.org/p/chromium/issues/detail?id=1123457

Comment 8

[Jonathan Kew [:jfkthame]]

Thanks for the comment, that helps to clarify things.

Does this imply, then, that Example 22 in the spec is wrong, or at least quite misleading? As shown there, it does not produce the claimed rendering (compare https://codepen.io/jfkthame/pen/mdmyJdN), because the counters instantiated by counter-reset on the <body> element are inherited in preference to the newly-instantiated ones created by the later counter-reset properties on the headings.

Comment 9

[Mats Palmgren (inactive)]

Does this imply, then, that Example 22 in the spec is wrong, or at least quite misleading?

Yes, that example is wrong. They should probably just use counter-set instead, to avoid nested counter scopes with the same name, like so:

body { counter-reset: h1 h2 h3; }
h1   { counter-increment: h1; counter-set: h2 h3;}
h2   { counter-increment: h2; counter-set: h3; }
...

alternatively, if they want to illustrate the old sibling behavior, I guess they could use:

body { counter-reset: h1; }
h1   { counter-increment: h1; counter-reset: h2; }
h2   { counter-increment: h2; counter-reset: h3; }
...