[css-lists] Should list-item counter reset rule be in a UA stylesheet?

[emilio]

Or should it be browser-engine magic like the increment?

The TLDR is this. Gecko implements the counter reset as suggested in the appendix:

https://drafts.csswg.org/css-lists/#ua-stylesheet

Which is something like:

/* Set up ol and ul so that they scope the list-item counter */
ol, ul {
  counter-reset: list-item;
}

So the issue with doing it at the UA stylesheet level is that pages can override it.

We've received two reports of broken lists, the first of them is fixed, the second of them is from today. So arguably not a lot of breakage, but still worth discussing, I think.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1576802
• https://bugzilla.mozilla.org/show_bug.cgi?id=1545746

cc @MatsPalmgren @tabatkins

[SimonSapin]

I think preventing override can be done with an !important UA rule, it doesn’t have to be hard-coded magic. (I don’t have an opinion whether it should be prevented.)

[emilio]

If you do that then you break the authors doing ol { counter-reset: other-counter } which is not nice.

[css-meeting-bot]

The CSS Working Group just discussed Should list-item counter reset rule be in a UA stylesheet?.

The full IRC log of that discussion

<TabAtkins> Topic: Should list-item counter reset rule be in a UA stylesheet?
<astearns> github: https://github.com//issues/4244
<heycam> emilio: the CSS Lists spec says that ol and ul (should also include menu!) should have a counter-reset: list-item in the UA sheet
<heycam> .. we've had 2 regression reports, people overriding counter-reset
<heycam> ... the fix on the author side is trivial, adding list-item to the value
<heycam> ... afaik, the 2 regressions are fixed that way
<heycam> ... but we may want to think about whether we should make this reset magical
<heycam> ... the issue with making it magical, is that there's no way to override it to none
<heycam> TabAtkins: at the previous meeting, didn't we resolve to do the thing where if you don't mention list-item?
<heycam> emilio: that's for counter-increment
<heycam> ... should we do the same for counter-reset?
<heycam> ... the reason I didn't want to jump to do that, there's no way to override it to none
<heycam> ... could say you add the counter-reset, unless you explicitly set it to none
<heycam> ... so it's tricky
<heycam> ... not totally convinced we need to change it for compat, but I'd like to know if we do need it
<heycam> TabAtkins: if we wanted to express the reverse mbehavior, in non magical ways, you'd need something special for counter-reset
<heycam> ... the only way to do that within the syntax of counter-reset would be to add a function
<heycam> ... because there's no comma, must be an ident and possibly a number. if you add a number ident, that's just another counter
<heycam> ... if you wanted to change hte behavior, like with reversed lists, synatx would be to use a function rather than an ident
<heycam> ... could have a dont-reset(...) when you explicitly need to
<heycam> ... then if it's not explicitly mentioned in this way, it gets reset in this way
<heycam> emilio: not a fan
<heycam> AmeliaBR: counter-reset: dont-reset(list-item), xxx
<heycam> emilio: just looking for ideas if we needed to tackle this
<heycam> ... for now this is fine I think
<heycam> ... a more web compatible solution would be to always reset it, but then it's annoying you can't override it
<heycam> TabAtkins: you can override the use of it
<heycam> emilio: the browser's doing some extra accounting in the background, but the author just wouldn't use it
<heycam> s/emilio/TabAtkins/
<heycam> fremy: what happens if you don't reset, and you have a reversed list inside another reversed list?
<heycam> AmeliaBR: it's a nested counter
<heycam> fremy: if you're not resetting th ecounter, you have to consider the nested child as part of the main list
<heycam> ... does anyone want to implement that?
<heycam> emilio: I think it would work right now
<heycam> AmeliaBR: the list items handle if you're incrementing up or down
<heycam> emilio: we do the counting on the counter nodes, so we count the number of counter nodes that are in the same list
<heycam> ... I think it would work. mixing reversed and non-reversed lists would be fun...
<heycam> fremy: not sure it's a big problem if we cannot
<heycam> AmeliaBR: any interested in supporting reversed counters in general? counter-reset and reset it to the max value the counter would have?
<heycam> TabAtkins: so far no, since that's what reversed counters actually do in HTML
<TabAtkins> s/that's not/that's not what/
<TabAtkins> s/that's what/that's not what/
<TabAtkins> ScribeNick: TabAtkins

[debiru]

Why is it that counter-increment is explicitly stated in the specification to be implicitly applied (browser-engine magic), but counter-reset is not? It seems natural that both counter-increment and counter-reset are implicitly applied, or that both can be overridden simply by CSS rules, but I doubt that only counter-increment is implicitly applied.

As of 2022, I'm confused about the implicit behavior of counter-reset, which is not specifically mentioned in the specification, because it behaves differently in different browsers.