[css-counter-style] overriding symbolic counter styles.

@upsuper

Counter styles allows to override built-in counter styles (except for none / disc / decimal). Is there any use-case to justify doing this? Can we at least disallow overriding the list-style types?

/cc @upsuper @tabatkins

(I basically find it a bit silly that I need to pay hash lookups in parts of Gecko to paint a square :))

A more concrete proposal: Can we prevent from overriding square / circle / disclosure-open / disclosure-closed? That is, the list in https://drafts.csswg.org/css-counter-styles/#simple-symbolic?

It's not a huge deal if not I guess, but it's somewhat unfortunate.

The reason is that, theoretically, once you implement @counter-style you can just move all your built-in counter styles to being defined by the UA style sheet. We include the minimum amount of magic names to allow us to do reasonable fallback, and otherwise assume that this is exactly what happens, so all the other styles can be overridden.

That said, I don't care and don't think it's important; if you want more disallowed names I'm okay with that.

The argument for those four counter styles to be non-overridable is that, browsers have special rendering code for them, so not needing to go through the counter style resolution may simplify / accelerate some handling for certain implementation strategies.

Like I said, I'm fine with that. The current list is just a minimal list (tho... I forget why I added disc...). Expanding it to cover a few more of the weirder pre-existing ones is fine.

For reference, disc was made non-overridable in #1521.

Agenda+ to see if we still want to make the list of simple symbolic styles that Emilio lists (circle, square, disclosure-open, and disclosure-closed) non-overridable.

As I said in earlier comments, I'm fine with doing more non-overridable values, if UAs want it.

If we resolve for this proposal, #6201 becomes a non issue; the special formatting for disc, circle and square is baked in and we don't need to make any decisions about how they're rendered when font-family is changed in ::marker. That's a good thing, so I'm +1 for disc, circle, square.

The disclosures I'm less sure on; first because we don't have the legacy issues we do with the other three, but mainly because the special handling that comes with disclosure-closed (the glyph changes in RTL contexts) isn't available with any other counter style. So an author that needs this functionality must use these counter styles, and is stuck with whatever glyphs the UA chooses (but on the plus side, #6201 goes away completely). So I'm neutral for disclosure-open and disclosure-closed.

@faceless2

@faceless2 While this simplifies #6201, I don't think it becomes a non-issue, because even if you can't override symbolic counters, I guess you can extend them like @counter-style my-circle { system: extends circle; }, possibly changing symbols too. Should the UA enforce specific glyphs for that (using images or internal font), like it does for circle?

Hmm, good point. I agree the question to resolve is - if a "special" counter like disc, circle, square is extended, does it remain special?

If we try and propagate this "specialness" through inheritance, I can see it getting quite complex.

@counter-style my-circle { system: extends circle; suffix: ":" }   /* circle or \25E6? */
@counter-style my-circle2 { system: extends circle; symbols: \25E6 }   /* circle or \25E6? */
@counter-style my-circle3 { system: extends square; symbols: \25E6 }   /* circle or \25E6? */
@counter-style tmp { system: extends disc; symbols: A } 
@counter-style my-circle5 { system: extends tmp; symbols: \25E6 }   /* circle or \25E6? */

I guess there are probably three options:

The moment you extend a special type, it becomes not special. We lose the ability to change the prefix/suffix for special types, which seems like a loss.
You can extend a special type and it remains special unless "symbols" is overridden, at which point it becomes not special.
Extending a special type means specialness remains - presumably, transitively, as with my-circle5

I can see an argument for 1 or 2, but not 3 myself - it starts to get weird and complex for what is, ultimately, something we're only doing for compatibility.

Yeah, I think we should just do the simplest thing there. At least 2, but I'd be fine with 1.

2 implies that part of the marker may be normal text (like prefix and suffix), and part may be special (symbol). This seems unnecessarily tricky to implement. I prefer 1, which is what Chromium and Firefox currently do. Anyways, this discussion seems more suited for #6201.

The CSS Working Group just discussed [css-counter-style] overriding symbolic counter styles., and agreed to the following:

RESOLVED: When you extend a predefined symbolic you are extending the version defined in the spec
(edit) * RESOLVED: Make all predefined symbolic counter styles not overwritable

The full IRC log of that discussion

<dael> Topic: [css-counter-style] overriding symbolic counter styles.
<dael> github: https://github.com//issues/3584
<dael> TabAtkins: IN current spec I went conserivitive with locking down styles so could not be overwritten.
<dael> TabAtkins: After prodding I added a few things in addition to decimal. Disc. Emilio is asking for others not to be overwritable. rendered specially by browsers so requires a bit more work.
<dael> TabAtkins: I'm happy with this. You can make your own and give it your own name. Need sign off
<dael> astearns: Yes, there is the out of making your own. Do you think there is a compat problem where we will remove people's overrides?
<dael> TabAtkins: I strongly doubt. If you're doing a counter style named square that is not squares you're bringing it on yourself
<dael> astearns: Your special squares is the thing. Going back to normal boring squares is not that terrible
<dael> astearns: Any concerns with the change?
<dael> astearns: Prop: Make app predefined symbolic counter styles not overwritable
<dael> TabAtkins: All predefined symbolics
<dael> s/app/all
<dael> astearns: Obj?
<dael> Resolved: Make all predefined symbolic counter styles not overwritable
<dael> TabAtkins: What if you extend these?
<dael> TabAtkins: Two major options
<dael> TabAtkins: First is that whenever you extend a predefined counter style the thing you are extending is the spec version, not what browsers do. Means you might get slightly different glyph
<dael> TabAtkins: Still approx the same
<dael> TabAtkins: Other is doing more subtle thing where certain descriptors cause revert to version in spec. That still has complicaitons
<dael> TabAtkins: Prop: if you extend a predefined symbolic you are extending the version defined in spec not as rendered in browsers
<dael> fantasai: Not sure on this one
<dael> fantasai: Reasonable you might want to extend with some such as speak-as without effecting rendering
<dael> TabAtkins: Symbolics with speak-as best you can do it make them read decimal of counter. Doing that one something that doesn't render a number doesn't sound good
<dael> TabAtkins: Decimal is fine. Predefined symbolics where in spec you can render in other ways
<dael> fantasai: So this is just circle, disc type ones?
<dael> TabAtkins: Yeah
<dael> oriol: This is how FF and Chromium render so it is fine
<dael> astearns: Prop: When you extend a predefined symbolic you are extending the version defined in the spec
<dael> astearns: Obj?
<dael> RESOLVED: When you extend a predefined symbolic you are extending the version defined in the spec

Oops it seems only one resolution is recorded by the bot.

Official minutes at https://lists.w3.org/Archives/Public/www-style/2021Jun/0005.html

[css-counter-styles-3] Make all the predefined symbolics non-override…

[counter-style] Make all predefined symbolic styles non-overridable

Navigation Menu

Repository navigation

[css-counter-style] overriding symbolic counter styles. #3584

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-counter-style] overriding symbolic counter styles. #3584

Description

Activity

emilio commented on Feb 1, 2019

emilio commented on Feb 1, 2019

tabatkins commented on Feb 1, 2019

upsuper commented on Feb 2, 2019

tabatkins commented on Feb 5, 2019

Loirooriol commented on Apr 15, 2021

tabatkins commented on May 13, 2021

faceless2 commented on May 26, 2021

Loirooriol commented on May 26, 2021

faceless2 commented on May 26, 2021

tabatkins commented on May 26, 2021

Loirooriol commented on May 26, 2021

css-meeting-bot commented on Jun 2, 2021

upsuper commented on Jun 3, 2021

fantasai commented on Jun 3, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions