Bug 273557 – CSS counter-reset of the implicit list-item counter results in different values for content

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: CSS

[glmvc]

Created attachment 471240 [details]
Ordered list with generated markers and counter content that differs regarding the starting value

CSS counter-reset of the implicit list-item counter results in different values for the generated content of ::marker and for the counter() function in pseudo-elements.

Steps to reproduce:
1. Create an ordered list (<ol> element) in HTML
2. Set the counter-reset property of that <ol> element to "list-item" plus an integer > 0 for its initial value (e.g., counter-reset: list-item 3;).
3. Note that the values of the ::marker pseudo-elements start counting at "4", while the values generated by the counter() function start counting at "3".

As far as the behavior in other common browsers is concerned, the value for the counter() function in our example should also start at "4".

Here is a CodePen with different setups: https://codepen.io/glmvc/pen/OJGYZEV

[glmvc]

The provided CodePen demo also provides the behavior of a custom counter name "test" (<custom-ident>) and the use of the HTML start attribute.

Attached is an additional screenshot from a reduced test case that shows the difference between Safari, Chrome and Firefox regarding the content generated with the counter() function for the ::after pseudo-element.

[glmvc]

Created attachment 471278 [details]
Reduced test case showing the difference between Safari, Chrome and Firefox regarding the counter() function content

[Karl Dubost]

To minimize the interaction, I wanted to see what a very simple testcase would do.


<style>
ol.list-item           {counter-reset:     list-item 78;}
ol.list-item li        {counter-increment: list-item 1;}
ol.list-item li::after {content:           " - counter: " counter(list-item);}
</style>
<ol class="list-item">
  <li>First</li>
  <li>Second</li>
  <li>Third</li>
  <li>Fourth</li>
  <li>Fifth</li>
</ol>

We get all sort of things:

STP 193 (Safari)
79. First - counter: 78
80. Second - counter: 79
81. Third - counter: 80
82. Fourth - counter: 81
83. Fifth - counter: 82

Firefox Nightly 127.0a1 (2024-05-06)
79. First - counter: 79
80. Second - counter: 80
81. Third - counter: 81
82. Fourth - counter: 82
83. Fifth - counter: 83

Chrome Canary 126.0.6452.0
1. First - counter: 79
2. Second - counter: 80
3. Third - counter: 81
4. Fourth - counter: 82
5. Fifth - counter: 83

[Radar WebKit Bug Importer]

<rdar://problem/127753103>

[Karl Dubost]

Probably the most interesting part of this bug is the difference in between 

class="test"
class="list-item"

[Karl Dubost]

https://drafts.csswg.org/css-lists/#list-item-counter

> In addition to any explicitly defined counters that authors write in their styles, list items automatically increment a special list-item counter, which is used when generating the default marker string on list items (see list-style-type).

> Specifically, unless the counter-increment property explicitly specifies a different increment for the list-item counter, it must be incremented by 1 on every list item, or if the counter is reversed, it must be incremented by -1 on every list item instead, at the same time that counters are normally incremented (exactly as if the list item had list-item 1 or list-item -1 appended to their counter-increment value, including side-effects such as possibly instantiating a new counter, etc). This does not affect the specified or computed values of counter-increment.

Ah… This is a duplicate of Bug 260436

*** This bug has been marked as a duplicate of bug 260436 ***

[glmvc]

Strange that I didn't see this when I searched for "counter reset"...
Anyway, thanks for checking, and I'm sorry I didn't see there was already an entry.

[Karl Dubost]

No no. Thanks a lot for reporting. Do not worry too much about duplicates.