[css-lists] counter-reset in UA sheet causing some compat issues.

[emilio]

Gecko implements CSS lists as per spec, however no other browser does. This means that code like:

ol { counter-reset: none }

Does nothing on non-Gecko browsers, but break subsequent lists in Firefox because it overrides the UA sheet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1765827 for the most recent example of this.

Maybe the list-item counter-reset should be magically auto-added to ol/ul/menu instead of via a UA sheet? That prevents authors from removing it but it might be needed for compatibility.

[tabatkins]

Given that list-item incrementing is magical in a similar way (automatically increments unless you explicitly mention it in counter-increment), I'd be okay with adding a similar bit of magic for counter-reset on those elements.

[fantasai]

There's use cases for removing the counter-reset, though. Like if you want to split a numbered list into pieces with some commentary in between. Also element-specific UA magic is not great. (The list-item increment is tied into CSS in a more reasonable way: it's magic tied to display: list-item.)

[tabatkins]

Gosh I hate the grammar of the counter-* properties so much.

But hm, we actually got lucky here; none is already disallowed as a counter name. So counter-reset: list-item none; could be unambiguous, if we change the grammar to be [ <counter-name> [ <integer> | none ]? ]+; saying foo none would be a no-op (not resetting) for every other counter name, but for list-item in particular it would give us that "if you refer to it we don't do the magic" behavior that counter-increment gets.

[css-meeting-bot]

The CSS Working Group just discussed [css-lists] counter-reset in UA sheet causing some compat issues..

The full IRC log of that discussion

<emeyer> Topic: [css-lists] counter-reset in UA sheet causing some compat issues.
<emeyer> Github: https://github.com//issues/7227
<emeyer> emilio: This is about pages that do their own counters and adding them makes things add oddly. Not many examples of this, but we found some.
<emeyer> …I tend to think there should be a magical reset, which is unfortunate, but there are things you wouldn’t be able to do otherwise.
<emeyer> TabAtkins: Elika had two objections. 1: this wouldn’t be overridable, as it is now. If you mention a counter, it gets reset. There’s no way to do a no-op. But we got lucky here. We could allow `none` as a counter-reset value alongside integers, which would mean “don’t reset the counter”.
<emeyer> … 2: this triggers on specific HTML elements with no CSS reason for it. We’d like to avoid that if possible. I’m okay with some weird rules, especially around lists, but Elika strongly believes that’s a problem.
<emeyer> fantasai: I think we should avoid it if we can. How strong of a web compatibility problem is it?
<jfkthame> +1 to fantasai
<emeyer> …So that’s a question for the Safari and Blink teams.
<iank_> i'd need Rune to comment.
<emeyer> smfr: No info at the moment from the WebKit side.
<emeyer> astearns: Who should we ping at WebKit?
<emeyer> smfr: I’ll be the conduit.
<fantasai> Question is, can we get Blink and WebKit to align with Firefox on this, or do we really need to introduce this magic into the Web platform
<emeyer> astearns: So we’re taking this back to the issue for more information.
<emeyer> …It might be good to outline the possible ways forward for this there as well. if someone could add a summary after minutes are posted, that might help.