[css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA? · Issue #8636 · w3c/csswg-drafts (original) (raw)

Hmm. The RMCS doc was always intended to provide quick access to styles that people thought were good enough to acquire 'off the shelf', but the expectation was always that people could and would tweak them and rename them to suit their preferences.

In particular, you'll see that a while ago we began deconstructing the entries because affixes are very susceptible to change according to the context or author preference. For example, it is common in indic/seasian styles to not use the period as a separator, but there's no clear default alternative: some people use (...), some may use ...), in Burmese one may also use ...။, and these may change within a single document. If putting them in a registry and requiring browsers to support all of those, i think we will be offering users an overly rigid (or, if it includes all options, baroque) situation that the move to customised counter styles was meant to remove.

I'm not sure how the registry would decide on a 'standardised' approach for Burmese, for example, or how useful that would be.

It would also make life much more complicated if things need to be corrected – it's not always possible to get the right information about these counter styles on the first go round, and several have been changed so far.

The other thing is that we do sometimes need to change the styles defined, either because new information comes to light, or sometimes because the original style contained an error. This is not an issue when people are copying the styles into their own stylesheets – where they can change them at will and changes to our document will not affect them. But it may be more problematic if they have been set in concrete by the browser, making it difficult to change them, and by changing them will affect existing content.

We'll also be back in the game of trying to maintain interoperability. It's all well and good to say that browsers must support all the items in the registry, but browsers typically don't, and if they do then adding new items to the registry will involve a lot of lag before all engines support them, and probably a lot of persuasion, creating tests, tracking results, etc., too.

We don't have any of these problems at all at the moment, and i'm not keen to start introducing them. I'm not sure what the benefit is of introducing the registry, and whether it outweighs the problems and hassle involved in creating it and policing it.

So i have some misgivings...

(Personally, i'd prefer to use our energies in fixing some other areas that i think need it more, such as sideways values of writing-mode, horizontal-in-vertical support, text opacity cleanup for cursive scripts, logical keyword support, etc.)