search

w3c / predefined-counter-styles

Predefined Counter Styles
https://w3c.github.io/predefined-counter-styles/
Other
7 stars 14 forks source link

All of the Ready-Made Counter Styles will ship in browsers! #59

Open jensimmons opened 1 year ago

jensimmons commented 1 year ago

Yesterday, the CSS Working Group resolved for all of the Ready-Made Counter Styles to become officially part of what browsers are expected to ship as part of their support of CSS.

RESOLVED: Work with i18nWG to republish Ready-Made Counter Styles as a W3C Registry allowing CSSWG and/or i18nWG to update; update Counter Styles to require everything in the Registry

For more, read the full issue, and/or read the minutes of the discussion at yesterday's meeting: https://github.com/w3c/csswg-drafts/issues/8636#issuecomment-1591665495

r12a commented 1 year ago

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 made life much more complicated if things needed 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.

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.)

jensimmons commented 1 year ago

Do bring up such concerns on the other thread at https://github.com/w3c/csswg-drafts/issues/8636

It makes more sense to have one discussion there then to split the conversation into two places.

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.

It's not a tradeoff. Dropping styles into a UA stylesheet (or which mechanism a browser might choose to use) is not a lot of work.

r12a commented 1 year ago

Moved the comment to the other discussion thread, and added a couple of paragraphs.