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

[emilio]

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

[emilio]

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

[emilio]

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.

[tabatkins]

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.

[upsuper]

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.

[tabatkins]

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.

[Loirooriol]

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

[tabatkins]

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.

[faceless2]

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.

[Loirooriol]

@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?

[faceless2]

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:

1. 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.
2. You can extend a special type and it remains special unless "symbols" is overridden, at which point it becomes not special.
3. 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.

[tabatkins]

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