Supporting a growing number of "unit" values in `formatOptions`

[Westbrook]

trafficstars

Looking at get support in formatOptions for graphical measurements like "pixels", "points", and "picas", I've recently been reviewing the growing number of "please add these unit" issues in this repo:

• https://github.com/tc39/ecma402/issues/605
• https://github.com/tc39/ecma402/issues/503
• https://github.com/tc39/ecma402/issues/470

And found that starting from https://github.com/tc39/proposal-unified-intl-numberformat/issues/39 the team has been looking for ways to contain the shipped units/translations so as to keep browser builds down.

In support of that goal, I wonder if there would be appetite for a user space partnership with a proposal like https://github.com/tc39/ecma402/issues/434 wherein additional units could be added to the browser API from the outside as opposed to or as well as from within the browser? Much like we see in the @formatjs/intl-numberformat polyfill for this API, were there to be a Intl.NumberFormat.__addLocaleData equivalent method built into the NumberFormat API a user could load new translations to be leveraged by the browser directly within the API without having to have innumerable values supported by default.

[longlho]

@Westbrook there've been extensive discussions on this and I do believe there are some appetites but the main concern AFAIK is the prerequisite of a data spec for browsers to accept the same data interface, which is quite a huge undertaking. ECMA402 currently doesn't even assume CLDR as the data source (in reality most implementations do though). The locale data format that formatjs provides are custom and unspecc'ed, though sourced from CLDR but has a bunch of custom de-duping + compression on top to reduce payload size. In general opening up custom data injection in browsers has been quite a can of worm.

Using the polyfill isn't ideal, but it can be selectively loaded to handle your use case. That's an alternative I can think of.

[Westbrook]

Using the polyfill isn't ideal, but it can be selectively loaded to handle your use case. That's an alternative I can think of.

This isn't actually true. When you want to add a completely unsupported unit you have to ALWAYS use the polyfill, and, to the best of my current understand, that polyfill actually rips out EVERYTHING of the native implementation and requires ALL units/translations, even the ones that would have otherwise been built-in to the browser. It's definitely an alternative.

We're also looking at some more custom paths where we merge an Intl.NumberFormat().format()ed number with a translated unit, but I'd really love to see a path towards this being build into the API.

[sffc]

Also see #210

This is a good idea, but as @longlho mentioned, we have a long way to go before this type of data patching is implementable in browsers. The good news is that we are making progress on ICU4X, which supports data patching, and once more browsers start migrating to it, we can restart conversations in ICU4X about whether to expose that to JavaScript developers.

[longlho]

@Westbrook you can technically use the polyfill as ponyfill if you do your own runtime detection