Intent to Ship: Intl.NumberFormat Unified API Proposal

21 views
Skip to first unread message

Frank Tang

unread,
May 31, 2019, 8:01:40 PM5/31/19
to v8-...@googlegroups.com, blink-dev, Frank Yung-Fong Tang, Adam Klein, Nebojša Ćirić, blink-api-ow...@chromium.org, Shane Carr, Jungshik Shin

Intend to ship for Chrome m77


Title: Intent to Ship: Intl.NumberFormat Unified API Proposal


Contact emails

ft...@chromium.com, sf...@chromium.com


Explainer

Stage 3 Proposal in TC39/ECMA402

https://github.com/tc39/proposal-unified-intl-numberformat


Spec

https://tc39.github.io/proposal-unified-intl-numberformat/section11/numberformat_diff_out.html

and

https://tc39.github.io/proposal-unified-intl-numberformat/section6/locales-currencies-tz_diff_out.html


Design Doc:

https://goo.gl/ZAtL1f


Why the tag review process is being skipped: JavaScript features do not need to go through a TAG review, as they already get significant scrutiny as part of the TC39 staging process.


Summary

Improves Intl.NumberFormat by adding support for measurement units, currency and sign display policies, and scientific and compact notation.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/$20ftang%7Csort:date/blink-dev/q3U7sPOG1uo/M7XZU7fxAwAJ


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo link

https://github.com/tc39/proposal-unified-intl-numberformat


Debuggability

Nothing special.


Risks

Interoperability and Compatibility

This API change the pre-existing Intl.NumberFormat API by adding new options to control the formatted output. It is advanced to TC39 Stage 3 in the end of Oct 2018. Engineer from Firefox team is supporting this proposal .


Ergonomics

The implementation depend on newer ICU class LocalizedNumberFormatter class, which require us to switch from the old NumberFormat. The switching in cl  1392233 speed up the Intl.NumberFormat constructor x4 in speed.

During the prototype phrase we identify a size increase issue of this proposal and work with the ECMA402 committee to reduce the scope of the number of “units” supported in the proposal.


Activation

Web developers could use the API immediately upon our shipment, based on the usage of previous well supported Intl.NumberFormat object.



Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.


Tests under tc39/test262 includes many tests to test this API.

Tests with “features: [Intl.NumberFormat-unified]” under test/intl402/NumberFormat/

Also tests under src/v8/test/intl/number-format/unified/


Entry on the feature dashboard

https://www.chromestatus.com/feature/5430420699086848




Philip Jägenstedt

unread,
Jun 3, 2019, 5:22:34 AM6/3/19
to Frank Tang, v8-...@googlegroups.com, blink-dev, Frank Yung-Fong Tang, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Shane Carr, Jungshik Shin
A few questions, this is the first TC39 intent I've looked closely at...

There are concrete examples of the new things in https://github.com/tc39/proposal-unified-intl-numberformat. Currently, in Chrome 74, the example in "I. Units" throws RangeError, while the example in "II. Scientific and Compact Notation" just returns "987,654,321", which isn't the expected value.

Given this, how should web developers detect support for these new things? Is there a polyfill in Babel?

Also, will Chromium be the first browser engine to ship support for this? Are there bugs filed for shipping it in Gecko and WebKit too?

Thanks!

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAOcELL-eWi2Q6%3D9S%3DxRo5cgXbSDgHAUym7e-O_TsXgLggS0wJA%40mail.gmail.com.

Frank Tang (譚永鋒)

unread,
Jun 3, 2019, 11:11:08 AM6/3/19
to Philip Jägenstedt, Daniel Ehrenberg, v8-...@googlegroups.com, blink-dev, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Shane Carr, Jungshik Shin
--
Frank Yung-Fong Tang
譚永鋒 / 🌭🍊 
Sr. Software Engineer 

Shane Carr

unread,
Jun 3, 2019, 12:50:14 PM6/3/19
to Frank Tang (譚永鋒), Philip Jägenstedt, Daniel Ehrenberg, v8-...@googlegroups.com, blink-dev, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Jungshik Shin
Hi Philip,

Good questions.  For the RangeError, the new style="unit" causes that in older browsers because that style is not recognized.  This is expected behavior because formatting a number without any kind of unit (when a unit was requested) changes the semantic meaning of the output and therefore is something that should be forbidden.  The new notation="compact" does not do this, which is okay because compact notation is locale-dependent (some locales, like Italian and German, don't have compact notation except for very large numbers), and it does not change the semantic meaning of the number; "50K" and "50,000" are the same number expressed in different ways.  Here is some related discussion.

For feature detection: RangeError can be used to detect the lack of style="unit"; for all other features, resolvedOptions() can be used.  If your input option (like "notation") is not present in resolvedOptions(), then the browser doesn't support that option.

Yes, Chromium is the first browser to ship this feature.  My understanding is that Mozilla is a bit backlogged with work on other Intl proposals, also ones that Chrome has recently shipped (Intl.ListFormat, Intl.RelativeTimeFormat, Intl.Locale), but they will get to this one in the not-so-distant future.  Apple does not seem to have an engineer dedicated to Intl and instead relies on community contributions to add support in WebKit.

Shane

P.S. Thanks Frank for your work on implementing this proposal and making Chrome the industry leader for i18n support in JavaScript!

Philip Jägenstedt

unread,
Jun 5, 2019, 6:33:03 AM6/5/19
to Shane Carr, Frank Tang (譚永鋒), Daniel Ehrenberg, v8-...@googlegroups.com, blink-dev, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Jungshik Shin
Thanks Shane!

I filed https://github.com/tc39/proposal-unified-intl-numberformat/issues/45 to ask for feature detection guidance in the README, hope that makes sense. (If not, just ignore.)

Given that this has reached stage 3 in the TC39 process I think we can trust that it has been seen and vetted by other potential implementers, but it'd still be great to ensure there are bugs filed, pointing out that this is on track to shipping in Chrome.

LGTM1

Yoav Weiss

unread,
Jun 6, 2019, 5:25:00 AM6/6/19
to Philip Jägenstedt, Shane Carr, Frank Tang (譚永鋒), Daniel Ehrenberg, v8-...@googlegroups.com, blink-dev, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Jungshik Shin
LGTM2

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfx9gEeL-%3DFgaFZ1u5Hwza4y%3DvW5k5CXY-%2Bibj7jQ-CtQ%40mail.gmail.com.

Chris Harrelson

unread,
Jun 6, 2019, 10:14:28 AM6/6/19
to Yoav Weiss, Philip Jägenstedt, Shane Carr, Frank Tang (譚永鋒), Daniel Ehrenberg, v8-...@googlegroups.com, blink-dev, Adam Klein, Nebojša Ćirić, blink-api-owners-discuss, Jungshik Shin
Reply all
Reply to author
Forward
0 new messages