-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-lists] counter-reset in UA sheet causing some compat issues. #7227
Comments
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. |
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 |
Gosh I hate the grammar of the counter-* properties so much. But hm, we actually got lucky here; |
The CSS Working Group just discussed 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. |
Gecko implements CSS lists as per spec, however no other browser does. This means that code like:
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.
The text was updated successfully, but these errors were encountered: