User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

This bug is visible when three things happen

1. There is either an <ul> or <ol> item higher up in the html
2. the li::marker pseudo-element's content value has counter changed from the default. eg:
   ol li::marker {
   content: counters(list-item, ".");
   }
3. The <ol> with the incorrect counter issue is nested in a higher element
   eg:
   <div>
   <ol>
   <li>*</li>
   <li>**</li>
   </ol>
   </div>

Actual results:

The actual occurrence can been viewed in the code snippet below:

https://codepen.io/Alx-Gdnr-Pen/pen/VwYbzOo

The list items in an ordered list start with nested counters instead of top-level ones

Expected results:

The list items in an ordered list should not start with nested counters (should start at 1, 2, 3, etc for top-level list items)

So I think this is somewhat expected given how CSS counters work... But this may be a legit occurrence of the same root cause as bug 1548753...

Ya. Let's wait for the fix of bug 1548753

The priority flag is not set for this bug.
:mats, could you have a look please?

For more information, please visit auto_nag documentation.

I'm putting this at P2. I'd like to get to a resolution for bug 1548753.

Now that we triage by severity, setting this bug's priority to P2 to represent near-term backlog status. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

FWIW, I'm seeing several other problems with counters in <ol> that may or may not be related to the ones reported so far here.
https://codepen.io/kcarmody/pen/xxVgxPb
https://codepen.io/kcarmody/pen/WNwRNMy
https://codepen.io/kcarmody/pen/xxVgxjG

(In reply to Kevin Carmody from comment #6)

https://codepen.io/kcarmody/pen/xxVgxPb

This is expected because counter-* properties don't apply to marker per spec: https://www.w3.org/TR/css-lists-3/#marker-properties

That can be controlled by layout.css.marker.restricted in about:config

https://codepen.io/kcarmody/pen/WNwRNMy

This one is also a bit subtle, but Firefox is still right. That's bug 1545746 / https://github.com/w3c/csswg-drafts/issues/4244.

TLDR ol elements by default reset the built-in list-item counter in a UA stylesheet. You're overriding that rule. You really want ol { counter-reset: verse list-item; }. Then :marker with one colon is just invalid so that rule just doesn't apply, you're just seeing the built-in counter.

https://codepen.io/kcarmody/pen/xxVgxjG

That's a different manifestation of the above. ol { counter-reset: section } is overriding the list-item counter-reset that ol usually have. If this comes up a lot, then we should resolve to unconditionally resetting the counter in https://github.com/w3c/csswg-drafts/issues/4244 I guess. But what authors ought to do per the standard is using counter-reset: section list-item.

Thanks, Emilio. I take it that you mean ol {counter-reset: list-item} rather than ol {counter-reset section list-item} or ol {counter-reset: verse list-item}.

Changing the third of my demos from a custom counter to list-item shows the same behavior:
https://codepen.io/kcarmody/pen/VwaPzzy
The 2.3.4 item is at the same level as the 2.3 item but it's numbered as if it were at the level below, and similarly for the 2.4 item and the 2.5 item.

Shouldn't FF simply ignore counter properties for ::marker since it's against spec, like Chrome does? Instead it seems to attempt to support it but in an inconsistent and buggy way.

(In reply to Kevin Carmody from comment #8)

Thanks, Emilio. I take it that you mean ol {counter-reset: list-item} rather than ol {counter-reset section list-item} or ol {counter-reset: verse list-item}.

Well if you want to use another counter you want to reset both. But sure you may want to just use list-item.

Changing the third of my demos from a custom counter to list-item shows the same behavior:
https://codepen.io/kcarmody/pen/VwaPzzy
The 2.3.4 item is at the same level as the 2.3 item but it's numbered as if it were at the level below, and similarly for the 2.4 item and the 2.5 item.

That is bug 1548753, and it is because your nested <ol>s are not inside a <li>.

Shouldn't FF simply ignore counter properties for ::marker since it's against spec, like Chrome does? Instead it seems to attempt to support it but in an inconsistent and buggy way.

Can you clarify? How are we not ignoring the counter properties on ::marker? Chrome doesn't use counters to implement lists, which is a totally different thing.

Thanks again, Emilio. On your third point, check these out in both FF and Chrome:

https://codepen.io/kcarmody/pen/xxVgxPb
https://codepen.io/kcarmody/pen/WNwRNMy - dotless1 and dotless2

All three of these examples use counter properties in either :marker or ::marker.

In the first example, with li::marker {counter-increment: verse; content: counter(verse)}, FF displays flush right zeros instead of item numbers, but Chrome ignores the li::marker and outputs default markers.

In the second example, FF displays markers which are not reset from the previous ol, apparently ignoring ol {counter-reset: verse} but using li:marker {counter(verse)} almost as if it were li::marker {counter(list-item)} with list-item not reset. Chrome ignores all this and outputs default markers.

In the third example, with li::marker {content: counter(list-item)}, FF displays markers without dots, but Chrome outputs default markers.

(In reply to Kevin Carmody from comment #10)

In the first example, with li::marker {counter-increment: verse; content: counter(verse)}, FF displays flush right zeros instead of item numbers, but Chrome ignores the li::marker and outputs default markers.

The zeros are because the counter verse in incremented within li::marker. If it's incremented in li instead, the zeros become item numbers, but still flush right.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:emilio, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

This works the same as other browsers now.