[css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?

[vitorroriz]

At https://w3c.github.io/csswg-drafts/css-counter-styles/#additional-predefined spec says:

The Internationalization Working Group maintains a large list of ready-made @counter-style rules for various world languages in their Ready-made Counter Styles document. [predefined-counter-styles]

These additional counter styles are not intended to be supported by user-agents by default, but can be used by users or authors copying them directly into style sheets.

Is there a reason why these are not intended to be supported by user-agent or should some, or all, of them be moved to predefined styles?

[gsnedders]

009fab0 seems to be the commit that removed many of them from the spec

Unfortunately I don't know how to easily find what resolutions that commit refers to (given mostly they're just in weekly minutes emails).

[gsnedders]

These from 2012 and 2011 hopefully cover relevant resolutions.

https://lists.w3.org/Archives/Public/www-style/2011Nov/0814.html seems to contain the original resolution to split Counter Styles out of Lists, so Lists could progress to CR separately (which it still hasn't):

RESOLVED: split predefined counter styles into a separate spec

https://lists.w3.org/Archives/Public/www-style/2012Aug/0899.html seems to cover dropping many of them from Counter Styles:

RESOLVED: Move @counter-style rule and symbols() function to the counter styles spec. Retain in that spec the 2.0, 2.1 and the six way cjk ideographic split (which is marked at-risk). Move rest of counter styles to registry on W3C wiki.

It's less clear here in the minutes what the motivation here? It sounds like the WG was just unclear how many of the styles were correct; does the I18N IG have that confidence in their Note?

[tabatkins]

Mainly it's that the set was both large and likely to continue growing, and there was no reasonable place to split it and say "these are the languages we're officially blessing with a shipped counter style, these are the languages we're not". So instead we went with the Schelling fence of "what css2 blessed" + the tiny handful that we know about that are too complex to reasonably handle in @counter-style.

It is not intended that the big list in Ready-Made Counter Styles ship in any browser; it's intended that authors include the @counter-style rule themselves when they're using such a language. The spec just does the work of actually constructing such a rule for the authors, so they just need to copy/paste.

[litherum]

What's the downside to including them in the browser? Seems like we'd be doing people a favor...

[tabatkins]

What I said above, essentially. And it means a pretty large addition to the UA stylesheet.

I'm not opposed to changing that decision, but it does mean a continuing maintenance burden.

[svgeesus]

From memory (and this was over a decade ago) another motivation was to encourage browser devs to implement @counter-style because they were already complaining about a big list of list styles. So the argument was "implement this, then the list won't grow".

Pleased to see Safari TP 166 enables @counter-style

[litherum]

I must not be understanding something. The ready made counter styles list is implemented in terms of counter styles. So the list is only useful if the browser has already implemented counter styles. So, the browser's choice isn't "either implement this list or implement counter styles" but instead the browser's choice is "definitely implement counter styles, then after you're done, decide whether or not to use the thing you just implemented to implement a bunch of default counters that authors can just use without making every site define them themselves"

[litherum]

Mainly it's that the set was both large and likely to continue growing, and there was no reasonable place to split it and say "these are the languages we're officially blessing with a shipped counter style, these are the languages we're not".

I view the fact that the list is large and will continue growing as a non-issue (and maybe even a benefit).

Here's a proposal for a place to split it: "let's include every language we've ever heard of which can be modeled using @counter-style"

[tabatkins]

I seem to recall it being an issue back then, but if it's no longer an issue, then great! Happy to revisit the issue. ^_^

[svgeesus]

I must not be understanding something.

I probably didn't explain it well. The original lists were documented in spec prose, and the list kept growing, which was seen as an issue at the time. (There was originally pushback against standardizing the X11 color names, for example, because "that is a big list and makes my code bigger").

Inventing @counter-style was a way to prevent the list from growing and to enable authors for unsupported styles to add them to their pages.

Trimming down the official list was a stick-and-carrot way to encourage browser implementation.

[svgeesus]

@tab you closed this but it seems there is ongoing conversation about including these by default rather than making every page author copy-paste it. OK to re-open?

A disadvantage of the copy-paste route is maintenance: if we find that the foo style gets 219 to 234 wrong, updating in a browser is easy and getting every web page to updater is hard.

[tabatkins]

Yeah fine to reopen; at the time I closed it the question was, indeed, answered.

[litherum]

@counter-style makes perfect sense to support scripts that we don't know about. Just like AAT fonts don't require Unicode shaping data, hyphens:manual supports content-provided hyphenation locations, <br> allows custom line breaking positions, etc.

If browsers know how a particular script's counters work, and implementation is possible (because it uses the @counter-style infrastructure), it seems like browsers should support those counters by default, without the page having to implement/maintain it themselves. In general, script-specific internationalization should work by default. CSS already follows this design for script-specific shaping, script-specific hyphenation, script-specific line breaking, etc.

[jensimmons]

I do think the CSSWG should have a conversation in 2023 about including all of the styles defined in Ready-Made Counter Styles in browser UA styles.

Decisions made in the 90s regarding language support on the web do need reconsideration. The status quo provides support for multiple different ways to count using the numbering system that's dominant in western Europe, and zero ways to count using even one numbering system from the continent of Africa. "Because that would be too many, let's keep it to only supporting the ones we picked first" does not do justice for many cultures around the world.

it means a pretty large addition to the UA stylesheet.

And is there a practical downside to a large UA stylesheet in 2023? Kbs are cheaper than they used to be.

it does mean a continuing maintenance burden.

Do these change much? It seems rarely.

[tabatkins]

Decisions made in the 90s regarding language support on the web do need reconsideration.

We made this particular decision about a decade ago, fwiw. As @svgeesus said, it was done to placate browser devs at the time. See https://lists.w3.org/Archives/Public/www-style/2011Nov/0814.html for the discussion and resolution.

Do these change much? It seems rarely.

There've been updates to the list maybe once a year or so, if I'm recalling correctly. It's not a lot, but it is ongoing.

[tabatkins]

Oh I was very wrong about the update frequency; there've been 100 commits to the repo in the last 8 years, most of which are indeed substantive additions/tweaks to the algos.

Again, this isn't a lot, but it does mean we'll be regularly updating the list for correctness.

[svgeesus]

Oh I was very wrong about the update frequency; there've been 100 commits to the repo in the last 8 years, most of which are indeed substantive additions/tweaks to the algos.

Given the number of browser releases in the last 8 years, that seems a very manageable number of UA stylesheet updates.

So, are we doing this?

[dbaron]

Given the number of browser releases in the last 8 years, that seems a very manageable number of UA stylesheet updates.

I think it's worth noting that if this were part of what browsers ship, then those updates would at least require assessment of whether they posed web-compatibility problems. I don't know how much work those assessments would be, or how often they would lead to the conclusion that the change was not acceptable due to compatibility. But it might be worth reviewing some set of recent changes to see whether they would have had a risk of compatibility problems.

[css-meeting-bot]

The CSS Working Group just discussed [css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?, and agreed to the following:

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

The full IRC log of that discussion

<fantasai> ??: When we were implementing counter styles on webkit side, I saw this list maintained for Ready-made Counter Styles for different languages
<fantasai> ... but this was not intended to be supported by browsers
<fantasai> ... so I wanted to understand why
<fantasai> jensimmons: Proposal is to take this stylesheet and put it into the UA stylesheet for browsers
<fantasai> ... so that all these styles are supported by browsers out of the box
<emilio> q+
<fantasai> ... for all the languages equally, so devs don't have to copy-paste
<fantasai> TabAtkins: I have no objections to in or out
<dbaron> s/??/vitorroriz/
<fantasai> ... we agreed to move out at the time partially because we didn't want to show favoritism that we happened to have listed
<fantasai> ... so restricted to list in CSS2
<fantasai> ... but list has been enhanced substantially by i18nWG over last 8 years
<fantasai> ... so as long as implementers are fine with it, I'm OK too
<emilio> FWIW I think Gecko ships at least an early version of this? https://searchfox.org/mozilla-central/rev/fb55a4ee44a9a95d099aa806ca494eb988252ded/layout/style/res/counterstyles.css
<fantasai> ... dbaron did point out that some of these changes could have web-compat impacts
<fantasai> ... I reviewed the changes, given intended use cases and the practical use cases ppl use these for
<fantasai> ... I suspect web-compat for such changes are going to be minimal
<fantasai> ... I think this is going to be low chance of compat
<Rossen_> q?
<fantasai> ... and if author disagrees with what we do, they can override; spec allows this
<fantasai> ... just need to make sure that whatever we do, it's still easily editable by i18nwg
<fantasai> ... There was some discussion about putting UA styles in HTML stylesheet, but that would create a lot of friction for updates, so don't recommend
<fantasai> jensimmons: I think one issue that will come up, e.g. making content for WWDC, one of the examples I used made upper-serbo-croatian
<dbaron> I'd note that the UA styles here are for all document languages rather than just for HTML, and I *think* such UA styles don't go in the HTML spec...
<fantasai> ... term was used in the past, but in this day and age, would be better to use a different term...
<fantasai> ... but there's going to be some touchy political issues around naming these things
<fantasai> ... if in CSS, then we'd have to add aliases or something
<fantasai> ... so some homework for CSSWG over the years
<tantek> +1 jensimmons I saw chatter about that example as well
<fantasai> ... but feels important to do, to include all languages of the world not just those in CSS2
<TabAtkins> yeah, so long as we don't drop anything, just add aliases, it should always be fine
<fantasai> emilio: for the case Jen mentioned, keep old name around and add new if needed
<fantasai> emilio: ant to point out, Gecko ships an early version of this
<fantasai> s/ant/want/
<fantasai> emilio: I tend to think that we should really support this in the browser, don't care where they live
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to comment on process
<Rossen_> ack emilio
<TabAtkins> fantasai: I don't think the right thing is to fold into Counter Styles 3, that's focused on the mechanism of counter styles and we want this to go to Rec
<TabAtkins> fantasai: But this could be a document, maybe a Registry which is new and allows easy updates, and commision CSSWG and i18nWG to add new things to it, make it a joint publications
<bkardell_> registry is interesting
<florian> [that makes sense to me]
<TabAtkins> fantasai: And counter styles can require including everything in the registry
<fantasai> jensimmons: Benefit is better compat
<TabAtkins> fantasai: Just putting them in the same doc makes things harder to update
<fantasai> jensimmons: We don't really have interop between browsers for this
<fantasai> jensimmons: expecting that browsers will regularly ship all of them will help authors in that way
<fantasai> TabAtkins: I propose we take fantasai's idea, take into registry jointly published by CSSWG and i18nWG
<fantasai> TabAtkins: and have Counter Styles require everything in the registry
<fantasai> Rossen_: Any objections to that?
<gtalbot> [crickets stridulation noises]
<fantasai> RESOLVED: Work with i18nWG to republishe Ready-Made Counter Styles as a W3C Registry allowing CSSWG and/or i18nWG to update; update Counter Styles to require everything in the Registry

[r12a]

Do these change much? It seems rarely.

I have a good sized stack of changes that have built up because i haven't had time to deal with them. Hopefully, i'll be making a substantial number of changes next week. But i expect to make additional changes after that, as i research other orthographies.

[r12a]

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

[vitorroriz]

@r12a These are great points, thanks for joining the thread. Can you give more details on:

But it may be more problematic if they have been set in concrete by the browser, making it difficult to change them

The current specification allow authors to extend a rule and redefine specific descriptors of them, with system: extends <name>. So, if author would prefer a specific suffix, it would be quite easy to just extend an existent style and alter just that descriptor. Or they could even override most UA counter-styles, by redefining the rule with the same name. So I thought it wouldn't be so hard to change them. Or do you mean that if author needs to extend a UA style, they could define it as they want directly so it wouldn't be such a useful feature for them anyway?

[r12a]

fwiw, i just published 2 new versions of the Ready-made Counter Styles Note.

Changes included:

• Add nko-cardinal counter style.
• Change cyrillic style names containing 'serbo-croatian' to just 'serbian'.
• Add a numeric template for Warang Citi.
• Add 17 alphabetic templates: [Arabic] kashmiri, [Bengali] bangla, [Devanagari] bodo, dogri, konkani, maithili, marathi, sanskrit, sindhi, [Gujarati] gujarati-alpha, [Gurmukhi] punjabi, [Kannada] kannada-alpha, [Malayalam] malayalam-alpha, [Meetei] manipuri, [Ol Chiki] santali, [Oriya] odia, [Telugu] telugu.
• Add the following 12 numeric counter styles: [Balinese] balinese, [Bamum] bamum, [Javanese] javanese, [Kayah Li] kayah-li, [Lanna (Tai Tham)] lanna-hora, lanna-tham, [Limbu] limbu, [Mro] mro, [Nag Mundari] nag-mundari, [Newa] newa, [Sundanese] sundanese, [Tai Lü] tai-lue

(There is plenty more to come, once we've done the necessary research.)

[r12a]

The current specification allow authors to extend a rule and redefine specific descriptors of them, with system: extends .....

@vitorroriz here's what worries me: In an ideal world, i'd agree that it seems straightforward to use a UA supported style, and change it with extends where needed. However, i think that in practice, with the best will in the world, authors will often have to do some research before using many of the styles. Even if we support many more styles in the UA, there will still be some that aren't supported, and some that are not supported by all browsers, and the author won't know which those are without some research. If they want to use a style such as bangla they will have to first check whether or not it is supported interoperably by all the browsers they and their readers use. And they may also need to experiment a bit to check how/whether they need to extend it.

To me, it seems much simpler to me to just open up the Ready-made Counters doc, see that bangla is there, and copy-paste it to their CSS style sheet, replacing lines as needed. No need to worry about browser support or interop issues, and it's clear what the default syntax is. (We even make suggestions about alternative affixes.)

[jensimmons]

1. I do not believe even a tiny minority of web developers know that the Ready-made Counters doc exists. That's why I talked about it in What's new in CSS — to help spread the word. But a document like that will never get widespread evangelism. 99% of web developers do not know that the CSS Working Group exists, let alone the Internationalization Working Group. They don't know what web standards are. They do not look up things in any flavor of W3C document. They depend instead on other resources that represent what's supposed to be shipping in browsers.

2. I have great hope that browsers will align on whatever the CSSWG agrees should be done. It will take a year or so to get there — but it's incredibly doable for every browser to ship 100% interoperable implementations of the entire Ready-made Counters document. DevRel / evangelism can coordinate. We can ask Interop 2024 to help by publicizing test failures. The CSSWG is the right place to encourage such interoperability… Things are much different than they were 20 years ago, when it was very common for browsers to have done something quite different from each other with very little hope of getting to interoperability.

3. Many browsers already support more languages than what was listed by the CSSWG. It's already impossible to know which languages are supported in which browsers, because MDN documents what the spec says, not the current reality. By specifying a larger set and pushing for interoperability on that larger set, this reduces the amount of work for developers, not increases it. As it is now, it's likely a developer will try something in their favorite browser — and assume if it works/doesn't that's how it will work/not in every browser. They often do not test cross-browser. And will end up with missing support on platforms they are not checking. The above resolution is how to get to interoperability.

4. If these styles are part of what browser are expected to ship, then they will get far better documentation on MDN and other CSS resources — books, blogs, conference talks, videos, podcasts. There will be developer documentation for both the UA stylesheet, and for how to override it.

5. Personally, I really don't want us to stop at "these languages are supported because they were there first, all the rest are not important enough to be included — so go find this document hardly anyone knows about, and add support to your website for your language manually". There were many things baked into the web in the 1990s that favors English and other European (Latin-based / horizontal-tb, LTR) scripts as "correct", while the cultures of many countries are considered "not worthy". I expect everyone on the Internationalization Working Group does not believe this — and that's why you've dedicated years of work and tons of expertise to make the web truly international. But let's undo the wrongs of the past, and unbias the early choices as much as possible. Entire continents have few indigenous languages listed in what's "supposed to be" in the UA stylesheet (prior to the above resolution), while colonial languages are deeply represented. Don't we want to change this? We should make it as easy as possible to switch from "1, 2, 3" to another counter style. Not make it easy for a few cultures, while hard for most. We might not be able to get all cultures, or keep things perfectly up to date, but we can try. We can succeed 80-90% of the time, and give developers the tools they need to perfect support the other 10-20%.

[litherum]

A few additional points I'd like to make:

1. The ready-made counter styles definitions aren't going away. Authors can still create their own @counter-style rules which both A) can be tweaked at a finer-grained way than swapping out the whole counter style for another, and B) are forward-compatible and won't change with future browser updates.
2. I think much of the arguments above are making the perfect the enemy of the good. Are there people who want to specify in great detail the counter style algorithm to use on their webpages? Sure. Are there other people would just want the browser defaults for their language? Certainly.
3. This kind of "simple things simple, complex things possible" is central to the design of CSS. An analogy: it's possible for an author to implement letter-spacing themselves by wrapping every letter in their content in a <span> - and people can do that if they want super fine control over how letter spacing is applied. But we still offer the letter-spacing property for the people who just want the default behavior which is sufficient for most people.
4. If there are, in fact, corrections to be made to these ready-made counter styles, it's way easier to update ~3 major browsers than it is to update all the websites which use them. I also expect browsers would stay up-to-date with the spec, as updating these rules is essentially a data change, which is cheap from a browser developer's point of view.

[css-meeting-bot]

The CSS Working Group just discussed [css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?.

The full IRC log of that discussion

<fantasai> Topic: [css-counter-styles-3] Should "Ready-made Counter Styles" be supported by UA?
<fantasai> github: https://github.com//issues/8636
<emilio> TabAtkins: we agreed last week to change the ready-made counter-style doc into a registry
<emilio> ... and require must level support
<emilio> ... r12a commented and they want to make sure that people that want minor tweaks can copy and paste
<emilio> ... counter-argument from myles and jensimmons is that most people can do that with the UA sheet and most people don't know that document or the spec exists
<emilio> ... I agree with them, given how counter-styles work we don't restrict authors in any way
<r12a> q+
<emilio> ack r12a
<emilio> r12a: don't want to repeat the thread
<emilio> ... if myles and jensimmons think we can keep up with all the changes and are prepared for the other stuff that would be necessary
<emilio> ... getting stuff into the counter-styles spec or the registry is the easy part
<emilio> ... we also have to have tests and check that the stuff is supported and which ones are supported by which browser and so on and change browsers to implement as needed
<emilio> ... if they feel comfortable that it can be done then that's fine
<emilio> ... the thing about this doc is that it was designed to be very flexible so that we could change it easily
<emilio> ... it was never intended to be an exhaustive resource
<TabAtkins> q+
<emilio> ... having the registry makes it a lot more formal
<emilio> ... I don't have experience maintaining/running one
<florian> q+ to make a brief point about registries
<emilio> ... but if it makes it more formal we kinda have an additional problem which is what counter styles / languages do we want to support
<emilio> ... there are 7k languages in the world
<emilio> ... so those worry me a bit
<emilio> ... if other people think there are no major issues and that can be handled then that's great
<emilio> TabAtkins: that doc was extracted from the spec
<jensimmons> q+
<emilio> ... the intent was to always making it required
<emilio> ... it was removed because browsers didn't want at the time to carry a couple hundred of styles
<emilio> ... as we need to adopt more we can continue to support new communities and languages
<emilio> ... shouldn't make perfect the enemy of good and we can make good for a bunch of people
<miriam> ack florian
<Zakim> florian, you wanted to make a brief point about registries
<emilio> florian: I think the question is more about whether browsers should ship it, not about registry
<emilio> ... registry we can worry about separately
<miriam> ack jensimmons
<emilio> jensimmons: I appreciate the perspective from r12a and your context. Maybe this doc has been pretty good but not perfect guidance
<emilio> ... to go from that to putting it in browsers that might be a different story, maybe it's a bit more intimidating
<emilio> ... I do feel like that phrase (don't let the perfect be the enemy of good)
<florian> q+
<emilio> ... I'd like browsers shipping more of these by default
<TabAtkins> i also suspect that testing all these is best done by auto generation - throw a parser at it, create a standard set of tests out of it. that way we can (a) actually test the ones that exist and (b) keep up with updates easily
<emilio> ... I also think this could create a bit more attention about this
<emilio> ... and I think we would be in a better place than now
<emilio> +1 TabAtkins, was thinking the same
<emilio> florian: I think it'd be good to ship more than what we're shipping now, but I wonder how many of these are known to be good enough?
<emilio> ... if we're outfashioned by a decade that's not concerning, but maybe some are plain wrong
<emilio> ... specially some of the rarer languages
<r12a> q+
<emilio> ... on one hand it is great to get more languages
<miriam> ack florian
<emilio> ... do we have any way of knowing which counters are known good, which ones need tweaking, and which one are a first try but not known good?
<emilio> TabAtkins: we'd still recommend people use these I'm not sure that'd be worse
<emilio> florian: when we do that people do it deliberately
<emilio> ... but that takes less review to give it a go
<emilio> TabAtkins: and when we find errors, which we probably will more often if it's in browsers
<emilio> ... updating is a copy/paste operation
<miriam> ack r12a
<emilio> ... so it's trivial
<emilio> r12a: we tried to make them as accurate as we can but there've been changes to popular languages
<emilio> ... like hebrew / greek
<emilio> ... also name changes e.g. serbian recently
<emilio> ... we've made a bunch of changes to separators
<emilio> ... can't answer to how many are good or bad, we try that all of them are ok
<emilio> plinss: also languages change
<emilio> ... so we'd need to update in the future
<emilio> r12a: most of the newer styles are defined by you, maybe with some tweaks from the document, but it wouldn't change underneath
<emilio> ... if we decided that the best separator for ?? was this separator or other people's list would change
<jensimmons> q?
<jensimmons> q+
<emilio> ... currently you copy it and it stays the same until we decide
<emilio> plinss: I don't see it as precluding that, you can always copy it if you care about it
<miriam> ack fantasai
<Zakim> fantasai, you wanted to comment on back-compat
<emilio> fantasai: from a compat perspective there are some changes, for separator changes it's aesthetic and it probably doesn't have much impact
<emilio> ... number changes are harder
<emilio> ... I think we're fine with these having minor changes
<emilio> ... if we're not fine with those to exist in documents we should wait until the counter styles are more stable before baking them in
<r12a> I take the point that if things change in a way that the author doesn't like then they can still change it for themselves using the @charset approach
<jfkthame> q+
<miriam> ack jensimmons
<emilio> jensimmons: I think there are some interesting points made here, might be helpful to go back to the issue
<fantasai> s/are harder/can be more problematic, especially if there are cross-references to it; but then, if there are manual cross-references, the author is more likely to notice if there's an actual error and switch the style/
<fantasai> s/charset/counter-style/
<miriam> ack jfkthame
<emilio> TabAtkins: yeah if there are no major objections to the resolution we should continue no change
<emilio> jfkthame: this is a bit parallel to a recent change in CLDR which affected date formatting in some languages
<r12a> q+ to talk about publicising the counter styles
<emilio> ... it caused a fair amount of compat pain
<emilio> ... I could see that happening around this
<emilio> ... sites are sometimes fragile to this stuff
<miriam> ack r12a
<Zakim> r12a, you wanted to talk about publicising the counter styles
<emilio> r12a: if something changes about the UA the author can still reverse it manually
<emilio> ... people brought up that not many people knew about it, but it'd be useful to point to it from mdn
<emilio> miriam: let's take it back to the issue then

[aphillips]

I was actioned by I18N-WG in this call to respond to this issue. Adding wider built-in support for other languages/cultures is generally a good thing: it is our mission to encourage wider availability of linguistic/cultural support in the Web, with no culture, language, or writing tradition excluded.

I18N is concerned (for the reasons @r12a enumerates elsewhere) that converting our work in this space into a registry might be a maintenance headache unless approached carefully. The ready-made counter styles are meant to be useful to page authors whose linguistic or cultural needs are not built-in to browsers. At the same time, we have not stabilized the data we capture and are continually striving to improve the styles provided. Registries (and a requirement for browsers to implement the registry) generally carry a certain level of stability guarantee.

We believe we would support CSSWG operating a registry of counter styles given appropriate thought into gathering, vetting, and updating styles.