-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting a growing number of "unit" values in formatOptions
#607
Comments
@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). 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 |
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. |
@Westbrook you can technically use the polyfill as ponyfill if you do your own runtime detection |
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:And found that starting from tc39/proposal-unified-intl-numberformat#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 #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 aIntl.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.The text was updated successfully, but these errors were encountered: