Re: [blink-dev] Re: [v8-dev] Re: [v8-users] Intent to Ship: Intl.Segmenter

[Frank Tang]

Ping, still needs the third approval.

On Fri, Aug 21, 2020 at 1:12 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Fri, Aug 21, 2020 at 12:24 PM Yoav Weiss  wrote:
>
>> *LGTM1*
>>
>> On Fri, Aug 21, 2020 at 6:43 PM Joshua Bell  wrote:
>>
>>>
>>>
>>> On Fri, Aug 21, 2020 at 1:16 AM Ross Kirsling 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Aug 21, 2020 at 12:05 AM Frank Tang  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 18, 2020 at 1:33 AM Yoav Weiss  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 18, 2020 at 1:10 AM Frank Tang 
>>>>>> wrote:
>>>>>>
>>>>>>> For m87
>>>>>>>
>>>>>>> Contact emailsft...@chromium.org, s...@chromium.org
>>>>>>>
>>>>>>> Explainer
>>>>>>> https://github.com/tc39/proposal-intl-segmenter
>>>>>>>
>>>>>>> Specificationhttps://tc39.github.io/proposal-intl-segmenter/
>>>>>>>
>>>>>>> Design docs
>>>>>>>
>>>>>>> https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
>>>>>>>
>>>>>>> https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p
>>>>>>>
>>>>>>> TAG reviewreviewed by ECMA402 and TC39
>>>>>>>
>>>>>>> SummaryIntl.Segmenter implements methods for finding the location
>>>>>>> of boundaries in text, including grapheme, line, word and sentence 
>>>>>>> boundary
>>>>>>> analysis.
>>>>>>>
>>>>>>> Link to “Intent to Prototype” blink-dev discussion
>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/MXnlnDEdBgAJ
>>>>>>>
>>>>>>> Risks
>>>>>>>
>>>>>>>
>>>>>>> Interoperability and CompatibilityThe specification is moved to
>>>>>>> Stage 3 in TC39 2020-Jul meeting with support from ECMA402.
>>>>>>>
>>>>>>> *Gecko*: In development (
>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
>>>>>>>
>>>>>>
>>>>>> That issue seems stalled...
>>>>>>
>>>>> Zibi (ECMA402 members from Mozilla) could you comment about your
>>>>> understanding about how likely Gecko would support Intl.Segmenter?
>>>>>
>>>>>
>>>>>>
>>>>>>> *WebKit*: No signal
>>>>>>>
>>>>>>
>>>>>> Could you ask
>>>>>> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u>
>>>>>> for official signals from both?
>>>>>>
>>>>> Mathias - could you help?
>>>>> Ross / rkirsl...@gmail.com (TC39 member from Apple) could you comment
>>>>> about your understanding about how likely Safari would support
>>>>> Intl.Segmenter?
>>>>>
>>>>
>>>> Note that I work for Sony, not Apple, but I do work on JSC and I can
>>>> say that we have a finished implementation expected to land in the near
>>>> future:
>>>> https://bugs.webkit.org/show_bug.cgi?id=213638
>>>>
>>>>
>>>>>
>>>>>>> *Web developers*: No signals
>>>>>>>
>>>>>>
>>>>>> Who's asking for this? Why are we implementing? Do we believe it's
>>>>>> something developers will use?
>>>>>>
>>>>>
>>>>> This is really needed to replace the non-standard
>>>>> Intl.v8BreakIterator. We somehow shipped a non standard
>>>>> one  Intl.v8BreakIterator and ECMA402 and TC39 really think there is a 
>>>>> need
>>>>> to retire/obsolete/deprecated  Intl.v8BreakIterator but we need a standard
>>>>> one first ship so we can tell the developer how to adopt the standard one.
>>>>> According to
>>>>> https://www.chromestatus.com/metrics/feature/timeline/popularity/556 
>>>>> currently
>>>

Re: [v8-dev] Re: [v8-users] Intent to Ship: Intl.Segmenter

[Frank Tang]

On Fri, Aug 21, 2020 at 1:15 AM Ross Kirsling  wrote:

>
>
> On Fri, Aug 21, 2020 at 12:05 AM Frank Tang  wrote:
>
>>
>>
>> On Tue, Aug 18, 2020 at 1:33 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Tue, Aug 18, 2020 at 1:10 AM Frank Tang  wrote:
>>>
>>>> For m87
>>>>
>>>> Contact emailsft...@chromium.org, s...@chromium.org
>>>>
>>>> Explainer
>>>> https://github.com/tc39/proposal-intl-segmenter
>>>>
>>>> Specificationhttps://tc39.github.io/proposal-intl-segmenter/
>>>>
>>>> Design docs
>>>>
>>>> https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
>>>>
>>>> https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p
>>>>
>>>> TAG reviewreviewed by ECMA402 and TC39
>>>>
>>>> SummaryIntl.Segmenter implements methods for finding the location of
>>>> boundaries in text, including grapheme, line, word and sentence boundary
>>>> analysis.
>>>>
>>>> Link to “Intent to Prototype” blink-dev discussion
>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/MXnlnDEdBgAJ
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and CompatibilityThe specification is moved to Stage
>>>> 3 in TC39 2020-Jul meeting with support from ECMA402.
>>>>
>>>> *Gecko*: In development (
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
>>>>
>>>
>>> That issue seems stalled...
>>>
>> Zibi (ECMA402 members from Mozilla) could you comment about your
>> understanding about how likely Gecko would support Intl.Segmenter?
>>
>>
>>>
>>>> *WebKit*: No signal
>>>>
>>>
>>> Could you ask
>>> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u>
>>> for official signals from both?
>>>
>> Mathias - could you help?
>> Ross / rkirsl...@gmail.com (TC39 member from Apple) could you comment
>> about your understanding about how likely Safari would support
>> Intl.Segmenter?
>>
>
> Note that I work for Sony, not Apple, but I do work on JSC and I can say
> that we have a finished implementation expected to land in the near future:
> https://bugs.webkit.org/show_bug.cgi?id=213638
>

Sorry, my bad.

>
>
>
>>
>>>> *Web developers*: No signals
>>>>
>>>
>>> Who's asking for this? Why are we implementing? Do we believe it's
>>> something developers will use?
>>>
>>
>> This is really needed to replace the non-standard Intl.v8BreakIterator.
>> We somehow shipped a non standard one  Intl.v8BreakIterator and ECMA402 and
>> TC39 really think there is a need to
>> retire/obsolete/deprecated  Intl.v8BreakIterator but we need a standard one
>> first ship so we can tell the developer how to adopt the standard one.
>> According to
>> https://www.chromestatus.com/metrics/feature/timeline/popularity/556 
>> currently
>> 0.4% of all chrome page load use Intl.v8BreakIterator. and these are the
>> first target  we would them to move their code away from
>> Intl.v8BreakIterator to Intl.Segmenter . Even with just Chrome launch it,
>> it will be better that they stay using the chrome only Intl.v8BreakIterator
>> as today.
>>
>>
>>>
>>>>
>>>> ErgonomicsEngineer from Apple believe we should not add line break
>>>> support to the Intl.Segmenter because the developer may abuse the API and
>>>> perform text layout by themselves instead of depending on CSS. The line
>>>> break feature then were removed from the specification in the current 
>>>> shape.
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ?Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter
>>>>
>>>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=6891
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://

Re: [v8-dev] Re: [v8-users] Intent to Ship: Intl.Segmenter

[Frank Tang]

On Tue, Aug 18, 2020 at 1:33 AM Yoav Weiss  wrote:

>
>
> On Tue, Aug 18, 2020 at 1:10 AM Frank Tang  wrote:
>
>> For m87
>>
>> Contact emailsft...@chromium.org, s...@chromium.org
>>
>> Explainer
>> https://github.com/tc39/proposal-intl-segmenter
>>
>> Specificationhttps://tc39.github.io/proposal-intl-segmenter/
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
>>
>> https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p
>>
>> TAG reviewreviewed by ECMA402 and TC39
>>
>> SummaryIntl.Segmenter implements methods for finding the location of
>> boundaries in text, including grapheme, line, word and sentence boundary
>> analysis.
>>
>> Link to “Intent to Prototype” blink-dev discussion
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/MXnlnDEdBgAJ
>>
>> Risks
>>
>>
>> Interoperability and CompatibilityThe specification is moved to Stage 3
>> in TC39 2020-Jul meeting with support from ECMA402.
>>
>> *Gecko*: In development (
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)
>>
>
> That issue seems stalled...
>
Zibi (ECMA402 members from Mozilla) could you comment about your
understanding about how likely Gecko would support Intl.Segmenter?


>
>> *WebKit*: No signal
>>
>
> Could you ask
> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u>
> for official signals from both?
>
Mathias - could you help?
Ross / rkirsl...@gmail.com (TC39 member from Apple) could you comment about
your understanding about how likely Safari would support  Intl.Segmenter?



>
>> *Web developers*: No signals
>>
>
> Who's asking for this? Why are we implementing? Do we believe it's
> something developers will use?
>

This is really needed to replace the non-standard Intl.v8BreakIterator. We
somehow shipped a non standard one  Intl.v8BreakIterator and ECMA402 and
TC39 really think there is a need to
retire/obsolete/deprecated  Intl.v8BreakIterator but we need a standard one
first ship so we can tell the developer how to adopt the standard one.
According to
https://www.chromestatus.com/metrics/feature/timeline/popularity/556 currently
0.4% of all chrome page load use Intl.v8BreakIterator. and these are the
first target  we would them to move their code away from
Intl.v8BreakIterator to Intl.Segmenter . Even with just Chrome launch it,
it will be better that they stay using the chrome only Intl.v8BreakIterator
as today.


>
>>
>> ErgonomicsEngineer from Apple believe we should not add line break
>> support to the Intl.Segmenter because the developer may abuse the API and
>> perform text layout by themselves instead of depending on CSS. The line
>> break feature then were removed from the specification in the current shape.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter
>>
>> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=6891
>>
>> Link to entry on the Chrome Platform Status
>> https://www.chromestatus.com/feature/6099397733515264
>>
>> This intent message was generated by Chrome Platform Status
>> <https://www.chromestatus.com/>.
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/v8-users/CAOcELL8S5zsU0HuppQrz%2BTK59nChDWOtuNpDLgefeazAEbHm1g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/v8-users/CAOcELL8S5zsU0HuppQrz%2BTK59nChDWOtuNpDLgefeazAEbHm1g%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> --
> v8-dev mailing list
> v8-...@googlegroups.com
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails 

[v8-users] Intent to Ship: Intl.Segmenter

[Frank Tang]

For m87

Contact emailsft...@chromium.org, s...@chromium.org

Explainer
https://github.com/tc39/proposal-intl-segmenter

Specificationhttps://tc39.github.io/proposal-intl-segmenter/

Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p

TAG reviewreviewed by ECMA402 and TC39

SummaryIntl.Segmenter implements methods for finding the location of
boundaries in text, including grapheme, line, word and sentence boundary
analysis.

Link to “Intent to Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/g/blink-dev/c/muRQBwyzzPw/m/MXnlnDEdBgAJ

Risks


Interoperability and CompatibilityThe specification is moved to Stage 3 in
TC39 2020-Jul meeting with support from ECMA402.

*Gecko*: In development (
https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)

*WebKit*: No signal

*Web developers*: No signals

ErgonomicsEngineer from Apple believe we should not add line break support
to the Intl.Segmenter because the developer may abuse the API and perform
text layout by themselves instead of depending on CSS. The line break
feature then were removed from the specification in the current shape.


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

Is this feature fully tested by web-platform-tests

?Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter

Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=6891

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264

This intent message was generated by Chrome Platform Status
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8S5zsU0HuppQrz%2BTK59nChDWOtuNpDLgefeazAEbHm1g%40mail.gmail.com.

[v8-users] Intent to Prototype: Intl.Segmenter

[Frank Tang]

[Note: Resent due to message header problem. Sorry]Contact emails
ft...@chromium.org, s...@chromium.org

Explainer
https://github.com/tc39/proposal-intl-segmenter

Specificationhttps://tc39.github.io/proposal-intl-segmenter/

Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p

TAG reviewreview by ECMA402

SummaryIntl.Segmenter implements methods for finding the location of
boundaries in text, including grapheme, line, word and sentence boundary
analysis.

MotivationCurrently, chrome is shipped with Intl.v8BreakIterator - a non
standard way for similar functionality. According to
https://www.chromestatus.com/metrics/feature/timeline/popularity/556 on
2020 Feb there are 0.74% of the web page use it. Intl.Segmenter is the web
standard to replace it.

Risks


Interoperability and CompatibilityThe specification is moved to Stage 3 in
TC39 2020-Jul meeting with support from ECMA402.

*Gecko*: In development (
https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)

*WebKit*: No signal

*Web developers*: No signals

ErgonomicsEngineer from Apple believe we should not add line break support
to the Intl.Segmenter because the developer may abuse the API and perform
text layout by themselves instead of depending on CSS. The line break
feature then were removed from the specification in the current shape.


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

Is this feature fully tested by web-platform-tests

?Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264

This intent message was generated by Chrome Platform Status
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL-m7DZ5OAwZj9FqX9VKZKWYd_Qf0YeaXCs3YAEbcnPsKA%40mail.gmail.com.

[v8-users] Intent to Prototype: Intl.Segmenter

[Frank Tang]

Contact emailsft...@chromium.org, s...@chromium.org

Explainer
https://github.com/tc39/proposal-intl-segmenter

Specificationhttps://tc39.github.io/proposal-intl-segmenter/

Design docs
https://docs.google.com/document/d/1xugLpLmgRFnNXK8ztariTAbD2IXueDw1T3VNuuZCz8k/edit#heading=h.xgjl2srtytjt
https://docs.google.com/presentation/d/1X2zBU3bZ4ergVMWfubCsdnHFzeaDgqiTRJVgvNGjQBs/edit#slide=id.p

TAG reviewreview by ECMA402

SummaryIntl.Segmenter implements methods for finding the location of
boundaries in text, including grapheme, line, word and sentence boundary
analysis.

MotivationCurrently, chrome is shipped with Intl.v8BreakIterator - a non
standard way for similar functionality. According to
https://www.chromestatus.com/metrics/feature/timeline/popularity/556 on
2020 Feb there are 0.74% of the web page use it. Intl.Segmenter is the web
standard to replace it.

Risks


Interoperability and CompatibilityThe specification is moved to Stage 3 in
TC39 2020-Jul meeting with support from ECMA402.

*Gecko*: In development (
https://bugzilla.mozilla.org/show_bug.cgi?id=1423593)

*WebKit*: No signal

*Web developers*: No signals

ErgonomicsEngineer from Apple believe we should not add line break support
to the Intl.Segmenter because the developer may abuse the API and perform
text layout by themselves instead of depending on CSS. The line break
feature then were removed from the specification in the current shape.


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

Is this feature fully tested by web-platform-tests

?Yes https://github.com/tc39/test262/tree/master/test/intl402/Segmenter

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/6099397733515264

This intent message was generated by Chrome Platform Status
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8X3Dhf2uYYLbbxpx%2BR%2BF8vW%3DqZCK5Jfpiy8Wsyd%2BSuGw%40mail.gmail.com.

[v8-users] Re: [blink-dev] Re: Intent to Ship: Add fractionalSecondDigits option to Intl.DateTimeFormat

[Frank Tang]

ping

On Wed, Mar 18, 2020 at 3:05 PM Mounir Lamouri  wrote:

> non-owner LGTM based on the above. 2 out of the 3 ICU bugs were pointed by
> Mozilla in their bug tracker as a reason to not launch yet.
>
> -- Mounir
>
> On Wed, 18 Mar 2020 at 14:59, Frank Tang  wrote:
>
>> It start from a user request and I put together this PR. Mozilla folks
>> identified some bugs in the ICU library and we just fixed them and make it
>> available recently. The PR is not merged because ECMA 402 will only merge
>> this PR if one of the engine shipt it and since I draft the PR it will
>> depend on this launch to unblock the merge.
>>
>> It was pending on the fix of the following 3 ICU bugs and they are now
>> all fixed.
>> https://unicode-org.atlassian.net/browse/ICU-20967
>> https://unicode-org.atlassian.net/browse/ICU-20738 (assignee forget to
>> mark it but will soon)
>> https://unicode-org.atlassian.net/browse/ICU-20739
>>
>> These fix also make our v8 implementation pass some failed test in
>> https://chromium-review.googlesource.com/c/chromium/src/+/2090002
>> https://chromium-review.googlesource.com/c/v8/v8/+/2095394
>>
>> On Wed, Mar 18, 2020 at 12:32 PM Mounir Lamouri 
>> wrote:
>>
>>> Mozilla seems to have this implemented but Nightly only so I think it
>>> would be reasonable to have their position updated from "Public Support" to
>>> "In Development". FWIW, it seems that Mozilla is keeping this in Nightly
>>> because the spec wasn't stable but it was a while ago.
>>>
>>> I also think it would be reasonable to consider Web Developers to be
>>> positive as this came from a user request
>>> <https://github.com/tc39/ecma402/issues/300> that was initially on
>>> Stack Overflow
>>> <https://stackoverflow.com/questions/53477403/how-to-format-milliseconds-with-intl-datetimeformat-api>
>>>  and
>>> the same person said that solved their use case
>>> <https://github.com/tc39/ecma402/pull/347#issuecomment-494714886>.
>>>
>>> -- Mounir
>>>
>>> On Wed, 18 Mar 2020 at 11:56, Daniel Bratell 
>>> wrote:
>>>
>>>> What is the current state of the spec change? It looks like the PR is
>>>> still open and not much has happened since last autumn. Preferably there
>>>> should be an agreed upon spec before something is changes, or at the very
>>>> least, the spec change and the shipping should happen close to each other.
>>>>
>>>> /Daniel
>>>> On 2020-03-18 17:54, Frank Tang wrote:
>>>>
>>>> ping
>>>>
>>>> On Fri, Mar 13, 2020 at 12:50 PM Frank Tang  wrote:
>>>>
>>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>>> http://shorturl.at/adiZ4 Spec https://github.com/tc39/ecma402/pull/347 TAG
>>>>> review No TAG review since the TC39 and ECMA402 will cover that.
>>>>> Summary Enhance the Intl.DateTimeFormat API by adding a “
>>>>> fractionalSecondDigits” option to control the format of fractions of a
>>>>> second. Link to “Intent to Prototype” blink-dev discussion
>>>>> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Add$20millisecondDigits$20option$20to$20Intl.DateTimeFormat%7Csort:date/blink-dev/WXd9nh03a1M/z7QeIMgrBgAJ
>>>>> Risks
>>>>> Interoperability and Compatibility low. *Firefox*: Public support (
>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1568134) *Edge*: No
>>>>> public signals *Safari*: No public signals *Web developers*: No
>>>>> signals Ergonomics Part of the pre-existing ICU functionality w/o
>>>>> need of additional data. Activation Should be easy to use by using w/
>>>>> pre-existing Intl.DateTimeFormat Security low
>>>>> Debuggability nothing special. Will this feature be supported on all
>>>>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>>>>> WebView)? Yes Is this feature fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>> ? Yes Tests are added to test262
>>>>> ./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-invalid.js
>>>>> ./test/intl402/DateTimeFormat/constructor-options-throwing-getters-fractionalSecondDigits.js
>>>>> ./test/intl402/DateTimeFormat/taint-Object-prototype-fracti

[v8-users] Re: [blink-dev] Re: Intent to Ship: Add fractionalSecondDigits option to Intl.DateTimeFormat

[Frank Tang]

It start from a user request and I put together this PR. Mozilla folks
identified some bugs in the ICU library and we just fixed them and make it
available recently. The PR is not merged because ECMA 402 will only merge
this PR if one of the engine shipt it and since I draft the PR it will
depend on this launch to unblock the merge.

It was pending on the fix of the following 3 ICU bugs and they are now all
fixed.
https://unicode-org.atlassian.net/browse/ICU-20967
https://unicode-org.atlassian.net/browse/ICU-20738 (assignee forget to mark
it but will soon)
https://unicode-org.atlassian.net/browse/ICU-20739

These fix also make our v8 implementation pass some failed test in
https://chromium-review.googlesource.com/c/chromium/src/+/2090002
https://chromium-review.googlesource.com/c/v8/v8/+/2095394

On Wed, Mar 18, 2020 at 12:32 PM Mounir Lamouri  wrote:

> Mozilla seems to have this implemented but Nightly only so I think it
> would be reasonable to have their position updated from "Public Support" to
> "In Development". FWIW, it seems that Mozilla is keeping this in Nightly
> because the spec wasn't stable but it was a while ago.
>
> I also think it would be reasonable to consider Web Developers to be
> positive as this came from a user request
> <https://github.com/tc39/ecma402/issues/300> that was initially on Stack
> Overflow
> <https://stackoverflow.com/questions/53477403/how-to-format-milliseconds-with-intl-datetimeformat-api>
>  and
> the same person said that solved their use case
> <https://github.com/tc39/ecma402/pull/347#issuecomment-494714886>.
>
> -- Mounir
>
> On Wed, 18 Mar 2020 at 11:56, Daniel Bratell  wrote:
>
>> What is the current state of the spec change? It looks like the PR is
>> still open and not much has happened since last autumn. Preferably there
>> should be an agreed upon spec before something is changes, or at the very
>> least, the spec change and the shipping should happen close to each other.
>>
>> /Daniel
>> On 2020-03-18 17:54, Frank Tang wrote:
>>
>> ping
>>
>> On Fri, Mar 13, 2020 at 12:50 PM Frank Tang  wrote:
>>
>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>> http://shorturl.at/adiZ4 Spec https://github.com/tc39/ecma402/pull/347 TAG
>>> review No TAG review since the TC39 and ECMA402 will cover that. Summary
>>> Enhance the Intl.DateTimeFormat API by adding a “ fractionalSecondDigits”
>>> option to control the format of fractions of a second. Link to “Intent
>>> to Prototype” blink-dev discussion
>>> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Add$20millisecondDigits$20option$20to$20Intl.DateTimeFormat%7Csort:date/blink-dev/WXd9nh03a1M/z7QeIMgrBgAJ
>>> Risks
>>> Interoperability and Compatibility low. *Firefox*: Public support (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1568134) *Edge*: No public
>>> signals *Safari*: No public signals *Web developers*: No signals
>>> Ergonomics Part of the pre-existing ICU functionality w/o need of
>>> additional data. Activation Should be easy to use by using w/
>>> pre-existing Intl.DateTimeFormat Security low
>>> Debuggability nothing special. Will this feature be supported on all
>>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>>> WebView)? Yes Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ? Yes Tests are added to test262
>>> ./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-invalid.js
>>> ./test/intl402/DateTimeFormat/constructor-options-throwing-getters-fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/taint-Object-prototype-fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/constructor-options-order-fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-valid.js
>>> ./test/intl402/DateTimeFormat/prototype/formatRangeToParts/fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/prototype/resolvedOptions/order-fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/prototype/format/fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/prototype/formatRange/fractionalSecondDigits.js
>>> ./test/intl402/DateTimeFormat/prototype/formatToParts/fractionalSecondDigits.js
>>> Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=9284 Demo
>>> links http://shorturl.at/adiZ4 Link to entry on the Chrome Platform
>>> Status https://www.chromestatus.com/feature

[v8-users] Re: Intent to Ship: Add fractionalSecondDigits option to Intl.DateTimeFormat

[Frank Tang]

ping

On Fri, Mar 13, 2020 at 12:50 PM Frank Tang  wrote:

> Contact emails ft...@chromium.org,js...@chromium.org Explainer
> http://shorturl.at/adiZ4 Spec https://github.com/tc39/ecma402/pull/347 TAG
> review No TAG review since the TC39 and ECMA402 will cover that. Summary
> Enhance the Intl.DateTimeFormat API by adding a “ fractionalSecondDigits”
> option to control the format of fractions of a second. Link to “Intent to
> Prototype” blink-dev discussion
> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Add$20millisecondDigits$20option$20to$20Intl.DateTimeFormat%7Csort:date/blink-dev/WXd9nh03a1M/z7QeIMgrBgAJ
> Risks
> Interoperability and Compatibility low. *Firefox*: Public support (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1568134) *Edge*: No public
> signals *Safari*: No public signals *Web developers*: No signals
> Ergonomics Part of the pre-existing ICU functionality w/o need of
> additional data. Activation Should be easy to use by using w/
> pre-existing Intl.DateTimeFormat Security low
> Debuggability nothing special. Will this feature be supported on all six
> Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
> WebView)? Yes Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ? Yes Tests are added to test262
> ./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-invalid.js
> ./test/intl402/DateTimeFormat/constructor-options-throwing-getters-fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/taint-Object-prototype-fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/constructor-options-order-fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-valid.js
> ./test/intl402/DateTimeFormat/prototype/formatRangeToParts/fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/prototype/resolvedOptions/order-fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/prototype/format/fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/prototype/formatRange/fractionalSecondDigits.js
> ./test/intl402/DateTimeFormat/prototype/formatToParts/fractionalSecondDigits.js
> Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=9284 Demo
> links http://shorturl.at/adiZ4 Link to entry on the Chrome Platform Status
> https://www.chromestatus.com/feature/5704965743968256
> This intent message was generated by Chrome Platform Status
> <https://www.chromestatus.com/>.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL9W04fz2fEv52cv70LYKJtTm2JavowkCMEjEX6ma%3DaWaA%40mail.gmail.com.

[v8-users] Intent to Ship: Add fractionalSecondDigits option to Intl.DateTimeFormat

[Frank Tang]

Contact emails ft...@chromium.org,js...@chromium.org Explainer
http://shorturl.at/adiZ4 Spec https://github.com/tc39/ecma402/pull/347 TAG
review No TAG review since the TC39 and ECMA402 will cover that. Summary
Enhance the Intl.DateTimeFormat API by adding a “ fractionalSecondDigits”
option to control the format of fractions of a second. Link to “Intent to
Prototype” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Add$20millisecondDigits$20option$20to$20Intl.DateTimeFormat%7Csort:date/blink-dev/WXd9nh03a1M/z7QeIMgrBgAJ
Risks
Interoperability and Compatibility low. *Firefox*: Public support (
https://bugzilla.mozilla.org/show_bug.cgi?id=1568134) *Edge*: No public
signals *Safari*: No public signals *Web developers*: No signals Ergonomics
Part of the pre-existing ICU functionality w/o need of additional data.
Activation Should be easy to use by using w/ pre-existing
Intl.DateTimeFormat Security low
Debuggability nothing special. Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)? Yes Is this feature fully tested by web-platform-tests

? Yes Tests are added to test262
./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-invalid.js
./test/intl402/DateTimeFormat/constructor-options-throwing-getters-fractionalSecondDigits.js
./test/intl402/DateTimeFormat/taint-Object-prototype-fractionalSecondDigits.js
./test/intl402/DateTimeFormat/constructor-options-order-fractionalSecondDigits.js
./test/intl402/DateTimeFormat/constructor-options-fractionalSecondDigits-valid.js
./test/intl402/DateTimeFormat/prototype/formatRangeToParts/fractionalSecondDigits.js
./test/intl402/DateTimeFormat/prototype/resolvedOptions/order-fractionalSecondDigits.js
./test/intl402/DateTimeFormat/prototype/format/fractionalSecondDigits.js
./test/intl402/DateTimeFormat/prototype/formatRange/fractionalSecondDigits.js
./test/intl402/DateTimeFormat/prototype/formatToParts/fractionalSecondDigits.js
Tracking bug https://bugs.chromium.org/p/v8/issues/detail?id=9284 Demo links
http://shorturl.at/adiZ4 Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5704965743968256
This intent message was generated by Chrome Platform Status
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL-_3pp%3DdN1MzsC6%2ByoyNpN%2BK72KKcNC-O0Q2mUGf4kTKA%40mail.gmail.com.

[v8-users] Re: FW: Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

I still need the third LGTM from anAPI owner

(sffc is not an API owner)

On Tue, Jan 7, 2020 at 8:06 AM Shane Carr  wrote:

> LGTM
>
> The proposal is Stage 3.  It was officially promoted here
> <https://github.com/tc39/proposals/commit/9717f0dc700d17c464964f796275cd024f168cc7#diff-738bf168ca04c8cfc21d0903825cb5c9>
> .
>
> ‪On Tue, Jan 7, 2020 at 1:49 AM ‫امیرحسین‬‎ 
> wrote:‬
>
>>
>>
>>
>>
>> از گوشی هوشمند Samsung Galaxy ارسال شده است.
>>
>>
>>  پیام اصلی ----
>> از: امیرحسین 
>> تاریخ: ۲۰۲۰/۱/۷ ۳:۴۴ (GMT+03:30)
>> گیرنده: PhistucK , Frank Tang 
>> گیرنده کپی: amirhosinf...@gmail.com, Nebojša Ćirić ,
>> blink-api-owners-discuss ,
>> v8-...@googlegroups.com, Jungshik Shin , Shane Carr <
>> s...@google.com>, v8-users , Daniel Bratell <
>> bratel...@gmail.com>, Jakob Kummerow , Mathias
>> Bynens , Frank Yung-Fong Tang , Chris
>> Harrelson , blink-dev ,
>> Yoav Weiss , Adam Klein 
>> موضوع FW: Re: [blink-dev] Intent to Ship: Intl.DisplayNames
>>
>>
>>
>>
>>
>> از گوشی هوشمند Samsung Galaxy ارسال شده است.
>>
>>
>>  پیام اصلی 
>> از: امیرحسین 
>> تاریخ: ۲۰۲۰/۱/۷ ۳:۴۳ (GMT+03:30)
>> گیرنده: Frank Tang , PhistucK 
>> گیرنده کپی: amirhosinf...@gmail.com, Yoav Weiss , Chris
>> Harrelson , blink-api-owners-discuss <
>> blink-api-owners-disc...@chromium.org>, Daniel Bratell <
>> bratel...@gmail.com>, v8-...@googlegroups.com, v8-users <
>> v8-users@googlegroups.com>, Adam Klein , blink-dev <
>> blink-...@chromium.org>, Mathias Bynens , Frank
>> Yung-Fong Tang , Shane Carr , Nebojša
>> Ćirić , Jakob Kummerow ,
>> Jungshik Shin 
>> موضوع Re: [blink-dev] Intent to Ship: Intl.DisplayNames
>>
>>
>>
>>
>>
>> از گوشی هوشمند Samsung Galaxy ارسال شده است.
>>
>>
>>  پیام اصلی 
>> از: Frank Tang 
>> تاریخ: ۲۰۲۰/۱/۷ ۲:۰۶ (GMT+03:30)
>> گیرنده: PhistucK 
>> گیرنده کپی: Yoav Weiss , Chris Harrelson <
>> chris...@chromium.org>, blink-api-owners-discuss <
>> blink-api-owners-disc...@chromium.org>, Daniel Bratell <
>> bratel...@gmail.com>, v8-...@googlegroups.com, v8-users <
>> v8-users@googlegroups.com>, Adam Klein , blink-dev <
>> blink-...@chromium.org>, Mathias Bynens , Frank
>> Yung-Fong Tang , Shane Carr , Nebojša
>> Ćirić , Jakob Kummerow ,
>> Jungshik Shin 
>> موضوع Re: [blink-dev] Intent to Ship: Intl.DisplayNames
>>
>> I double check with BFS (Bradley Farias <https://github.com/bmeck> bmeck
>> <https://github.com/bmeck> bradley.m...@gmail.com)
>> He commented on
>>
>> https://github.com/tc39/proposal-intl-displaynames/issues/38#issuecomment-571320389
>>
>> as
>> "LGTM spec wise, there are a couple of README PRs outstanding it looks
>> like though; nothing to block on"
>>
>> I apologize for my previous misunderstanding of the conclusion in Oct
>> TC39 meeting and declare the reaching of Stage 3 w/o double check with BFS.
>> Now the pending clause of Stage 3 is fulfilled.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jan 6, 2020 at 10:16 AM PhistucK  wrote:
>>
>>> It is pending review, so not going to stage 3 just yet.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Mon, Jan 6, 2020 at 8:07 PM Frank Tang  wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 6, 2020 at 10:05 AM Frank Tang  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 5, 2020 at 11:21 PM Yoav Weiss  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 3, 2020 at 7:49 PM Frank Tang  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 2, 2020 at 10:34 AM Frank Tang 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> still need one more
>>>>>>>>
>>>>>>>> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson <
>>>>>>>> chris...@chromium.org> wrote:
>>>>>>>>
>>>>>>>>> LGTM2
>>>>>>>>>
>>>>>>>>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell <
>>>>>>>>> bratel...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> LGTM1
>>

[v8-users] Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

I double check with BFS (Bradley Farias <https://github.com/bmeck> bmeck
<https://github.com/bmeck> bradley.m...@gmail.com)
He commented on
https://github.com/tc39/proposal-intl-displaynames/issues/38#issuecomment-571320389

as
"LGTM spec wise, there are a couple of README PRs outstanding it looks like
though; nothing to block on"

I apologize for my previous misunderstanding of the conclusion in Oct TC39
meeting and declare the reaching of Stage 3 w/o double check with BFS. Now
the pending clause of Stage 3 is fulfilled.







On Mon, Jan 6, 2020 at 10:16 AM PhistucK  wrote:

> It is pending review, so not going to stage 3 just yet.
>
> ☆*PhistucK*
>
>
> On Mon, Jan 6, 2020 at 8:07 PM Frank Tang  wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 10:05 AM Frank Tang  wrote:
>>
>>>
>>>
>>> On Sun, Jan 5, 2020 at 11:21 PM Yoav Weiss  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 3, 2020 at 7:49 PM Frank Tang  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 2, 2020 at 10:34 AM Frank Tang  wrote:
>>>>>
>>>>>> still need one more
>>>>>>
>>>>>> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson <
>>>>>> chris...@chromium.org> wrote:
>>>>>>
>>>>>>> LGTM2
>>>>>>>
>>>>>>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> LGTM1
>>>>>>>>
>>>>>>>> /Daniel
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2019-12-26 23:03, Frank Tang wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>>>>>> https://github.com/tc39/proposal-intl-displaynames Spec
>>>>>>>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A
>>>>>>>> small JavaScript features, a TAG review is not required, as TC39 
>>>>>>>> already
>>>>>>>> provide significant technical oversight. Summary Provides a new
>>>>>>>> API to get localized names of language, region, script, currency codes 
>>>>>>>> of
>>>>>>>> international standard as well as commonly used names of date fields 
>>>>>>>> and
>>>>>>>> symbols. Link to “Intent to Prototype” blink-dev discussion
>>>>>>>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>>>>>>>> Risks
>>>>>>>> Interoperability and Compatibility This is a new API. It is
>>>>>>>> currently under TC39 Stage 3. *Firefox*: No public signals
>>>>>>>>
>>>>>>>> for mozilla , Zibi from mozilla were the original spec champion .
>>> They filed tracking bug in
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1557727
>>>
>>>> *Edge*: No public signals *Safari*: No public signals *Web developers*:
>>>>>>>> No signals
>>>>>>>>
>>>>>>>> I'm assuming that at least some of the above supported the proposal
>>>> in order for it to make it to stage 3...
>>>>
>>>
>>> TC39 meeting not to propose to Stage 3
>>>
>>> https://github.com/tc39/notes/blob/master/meetings/2019-10/october-2.md#intldisplaynames
>>>
>>
>> sorry. Typo. I mean to write " TC39 meeting note to..." not "TC39 meeting
>> not to..." fat finger missed a 'e' before I sent the reply.
>>
>>>
>>>
>>>
>>>
>>>>
>>>>> Ergonomics The implementation depend on pre-existing functions in
>>>>>>>> already linked in ICU library During the prototype phrase we identify 
>>>>>>>> no
>>>>>>>> small size increase impact since all the strings were already included 
>>>>>>>> to
>>>>>>>> support other Chrome functionality.
>>>>>>>>
>>>>>>>> The "Ergonomics" section refers to developer ergonomics of the
>>>> feature itself and how web developers would use it, not to the ergonomics
>>>> of Chromium engineers developing it.
>>>>
&g

[v8-users] Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

On Mon, Jan 6, 2020 at 10:05 AM Frank Tang  wrote:

>
>
> On Sun, Jan 5, 2020 at 11:21 PM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Jan 3, 2020 at 7:49 PM Frank Tang  wrote:
>>
>>>
>>>
>>> On Thu, Jan 2, 2020 at 10:34 AM Frank Tang  wrote:
>>>
>>>> still need one more
>>>>
>>>> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson 
>>>> wrote:
>>>>
>>>>> LGTM2
>>>>>
>>>>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
>>>>> wrote:
>>>>>
>>>>>> LGTM1
>>>>>>
>>>>>> /Daniel
>>>>>>
>>>>>>
>>>>>> On 2019-12-26 23:03, Frank Tang wrote:
>>>>>>
>>>>>>
>>>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>>>> https://github.com/tc39/proposal-intl-displaynames Spec
>>>>>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A
>>>>>> small JavaScript features, a TAG review is not required, as TC39 already
>>>>>> provide significant technical oversight. Summary Provides a new API
>>>>>> to get localized names of language, region, script, currency codes of
>>>>>> international standard as well as commonly used names of date fields and
>>>>>> symbols. Link to “Intent to Prototype” blink-dev discussion
>>>>>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>>>>>> Risks
>>>>>> Interoperability and Compatibility This is a new API. It is
>>>>>> currently under TC39 Stage 3. *Firefox*: No public signals
>>>>>>
>>>>>> for mozilla , Zibi from mozilla were the original spec champion .
> They filed tracking bug in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1557727
>
>> *Edge*: No public signals *Safari*: No public signals *Web developers*:
>>>>>> No signals
>>>>>>
>>>>>> I'm assuming that at least some of the above supported the proposal
>> in order for it to make it to stage 3...
>>
>
> TC39 meeting not to propose to Stage 3
>
> https://github.com/tc39/notes/blob/master/meetings/2019-10/october-2.md#intldisplaynames
>

sorry. Typo. I mean to write " TC39 meeting note to..." not "TC39 meeting
not to..." fat finger missed a 'e' before I sent the reply.

>
>
>
>
>>
>>> Ergonomics The implementation depend on pre-existing functions in
>>>>>> already linked in ICU library During the prototype phrase we identify no
>>>>>> small size increase impact since all the strings were already included to
>>>>>> support other Chrome functionality.
>>>>>>
>>>>>> The "Ergonomics" section refers to developer ergonomics of the
>> feature itself and how web developers would use it, not to the ergonomics
>> of Chromium engineers developing it.
>>
>
>
>
>>
>>
>>> Activation Web developers could use the API immediately upon our
>>>>>> shipment. Security Web developers could use the API immediately upon
>>>>>> our shipment.
>>>>>>
>>>>>> The "Security" section refers to the security considerations of the
>> feature, and whether we believe it puts users at risk. I believe the answer
>> is no, but can you confirm?
>>
>
> Agree. The answer is NO
>
>> Debuggability Nothing special. Will this feature be supported on all six
>>>>>> Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>>>>>> WebView)? Yes It will be supported on all platform. Is this feature
>>>>>> fully tested by web-platform-tests
>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>> ? Yes Tests were added into test262 before shipping it in chrome. 
>>>>>> Tracking
>>>>>> bug https://bugs.chromium.org/p/v8/issues/detail?id=8703 Link to
>>>>>> entry on the Chrome Platform Status
>>>>>> https://www.chromestatus.com/feature/4965112605573120
>>>>>> This intent message was generated by Chrome Platform Status
>>>>>> <https://www.chromestatus.com/>.
>>>>>> --
>>>>>> You received this message because you are subs

[v8-users] Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

On Sun, Jan 5, 2020 at 11:21 PM Yoav Weiss  wrote:

>
>
> On Fri, Jan 3, 2020 at 7:49 PM Frank Tang  wrote:
>
>>
>>
>> On Thu, Jan 2, 2020 at 10:34 AM Frank Tang  wrote:
>>
>>> still need one more
>>>
>>> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson 
>>> wrote:
>>>
>>>> LGTM2
>>>>
>>>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
>>>> wrote:
>>>>
>>>>> LGTM1
>>>>>
>>>>> /Daniel
>>>>>
>>>>>
>>>>> On 2019-12-26 23:03, Frank Tang wrote:
>>>>>
>>>>>
>>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>>> https://github.com/tc39/proposal-intl-displaynames Spec
>>>>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A small
>>>>> JavaScript features, a TAG review is not required, as TC39 already provide
>>>>> significant technical oversight. Summary Provides a new API to get
>>>>> localized names of language, region, script, currency codes of
>>>>> international standard as well as commonly used names of date fields and
>>>>> symbols. Link to “Intent to Prototype” blink-dev discussion
>>>>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>>>>> Risks
>>>>> Interoperability and Compatibility This is a new API. It is currently
>>>>> under TC39 Stage 3. *Firefox*: No public signals
>>>>>
>>>>> for mozilla , Zibi from mozilla were the original spec champion . They
filed tracking bug in
https://bugzilla.mozilla.org/show_bug.cgi?id=1557727

> *Edge*: No public signals *Safari*: No public signals *Web developers*:
>>>>> No signals
>>>>>
>>>>> I'm assuming that at least some of the above supported the proposal in
> order for it to make it to stage 3...
>

TC39 meeting not to propose to Stage 3
https://github.com/tc39/notes/blob/master/meetings/2019-10/october-2.md#intldisplaynames



>
>> Ergonomics The implementation depend on pre-existing functions in
>>>>> already linked in ICU library During the prototype phrase we identify no
>>>>> small size increase impact since all the strings were already included to
>>>>> support other Chrome functionality.
>>>>>
>>>>> The "Ergonomics" section refers to developer ergonomics of the feature
> itself and how web developers would use it, not to the ergonomics of
> Chromium engineers developing it.
>



>
>
>> Activation Web developers could use the API immediately upon our
>>>>> shipment. Security Web developers could use the API immediately upon
>>>>> our shipment.
>>>>>
>>>>> The "Security" section refers to the security considerations of the
> feature, and whether we believe it puts users at risk. I believe the answer
> is no, but can you confirm?
>

Agree. The answer is NO

> Debuggability Nothing special. Will this feature be supported on all six
>>>>> Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>>>>> WebView)? Yes It will be supported on all platform. Is this feature
>>>>> fully tested by web-platform-tests
>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>> ? Yes Tests were added into test262 before shipping it in chrome. Tracking
>>>>> bug https://bugs.chromium.org/p/v8/issues/detail?id=8703 Link to
>>>>> entry on the Chrome Platform Status
>>>>> https://www.chromestatus.com/feature/4965112605573120
>>>>> This intent message was generated by Chrome Platform Status
>>>>> <https://www.chromestatus.com/>.
>>>>> --
>>>>> 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+unsubscr...@chromium.org.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com?utm_medium=email_source=footer>

[v8-users] Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

On Thu, Jan 2, 2020 at 10:34 AM Frank Tang  wrote:

> still need one more
>
> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
>> wrote:
>>
>>> LGTM1
>>>
>>> /Daniel
>>>
>>>
>>> On 2019-12-26 23:03, Frank Tang wrote:
>>>
>>>
>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>> https://github.com/tc39/proposal-intl-displaynames Spec
>>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A small
>>> JavaScript features, a TAG review is not required, as TC39 already provide
>>> significant technical oversight. Summary Provides a new API to get
>>> localized names of language, region, script, currency codes of
>>> international standard as well as commonly used names of date fields and
>>> symbols. Link to “Intent to Prototype” blink-dev discussion
>>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>>> Risks
>>> Interoperability and Compatibility This is a new API. It is currently
>>> under TC39 Stage 3. *Firefox*: No public signals *Edge*: No public
>>> signals *Safari*: No public signals *Web developers*: No signals
>>> Ergonomics The implementation depend on pre-existing functions in
>>> already linked in ICU library During the prototype phrase we identify no
>>> small size increase impact since all the strings were already included to
>>> support other Chrome functionality. Activation Web developers could use
>>> the API immediately upon our shipment. Security Web developers could
>>> use the API immediately upon our shipment.
>>> Debuggability Nothing special. Will this feature be supported on all
>>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>>> WebView)? Yes It will be supported on all platform. Is this feature
>>> fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ? Yes Tests were added into test262 before shipping it in chrome. Tracking
>>> bug https://bugs.chromium.org/p/v8/issues/detail?id=8703 Link to entry
>>> on the Chrome Platform Status
>>> https://www.chromestatus.com/feature/4965112605573120
>>> This intent message was generated by Chrome Platform Status
>>> <https://www.chromestatus.com/>.
>>> --
>>> 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+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>> --
>>> 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+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b437b38-9b1a-3af6-b783-b8ff76ca1f01%40gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b437b38-9b1a-3af6-b783-b8ff76ca1f01%40gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8NOkN1N6i9_dXqTvO8CSD7wiJqh9BmG%3Dd4ckEKtV6e6g%40mail.gmail.com.

[v8-users] Re: [blink-dev] Intent to Ship: Intl.DisplayNames

[Frank Tang]

still need one more

On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson 
wrote:

> LGTM2
>
> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
> wrote:
>
>> LGTM1
>>
>> /Daniel
>>
>>
>> On 2019-12-26 23:03, Frank Tang wrote:
>>
>>
>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>> https://github.com/tc39/proposal-intl-displaynames Spec
>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A small
>> JavaScript features, a TAG review is not required, as TC39 already provide
>> significant technical oversight. Summary Provides a new API to get
>> localized names of language, region, script, currency codes of
>> international standard as well as commonly used names of date fields and
>> symbols. Link to “Intent to Prototype” blink-dev discussion
>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>> Risks
>> Interoperability and Compatibility This is a new API. It is currently
>> under TC39 Stage 3. *Firefox*: No public signals *Edge*: No public
>> signals *Safari*: No public signals *Web developers*: No signals
>> Ergonomics The implementation depend on pre-existing functions in
>> already linked in ICU library During the prototype phrase we identify no
>> small size increase impact since all the strings were already included to
>> support other Chrome functionality. Activation Web developers could use
>> the API immediately upon our shipment. Security Web developers could use
>> the API immediately upon our shipment.
>> Debuggability Nothing special. Will this feature be supported on all six
>> Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>> WebView)? Yes It will be supported on all platform. Is this feature
>> fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ? Yes Tests were added into test262 before shipping it in chrome. Tracking
>> bug https://bugs.chromium.org/p/v8/issues/detail?id=8703 Link to entry
>> on the Chrome Platform Status
>> https://www.chromestatus.com/feature/4965112605573120
>> This intent message was generated by Chrome Platform Status
>> <https://www.chromestatus.com/>.
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b437b38-9b1a-3af6-b783-b8ff76ca1f01%40gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0b437b38-9b1a-3af6-b783-b8ff76ca1f01%40gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL9TRxV53_o9Ch5pUbsBy1SpPt91_8%3Dyt8dOA%3DhVftca9w%40mail.gmail.com.

[v8-users] Intent to Ship: Intl.DisplayNames

[Frank Tang]

Contact emails ft...@chromium.org,js...@chromium.org Explainer
https://github.com/tc39/proposal-intl-displaynames Spec
https://tc39.github.io/proposal-intl-displaynames/ TAG review A small
JavaScript features, a TAG review is not required, as TC39 already provide
significant technical oversight. Summary Provides a new API to get
localized names of language, region, script, currency codes of
international standard as well as commonly used names of date fields and
symbols. Link to “Intent to Prototype” blink-dev discussion
https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
Risks
Interoperability and Compatibility This is a new API. It is currently under
TC39 Stage 3. *Firefox*: No public signals *Edge*: No public signals
*Safari*: No public signals *Web developers*: No signals Ergonomics The
implementation depend on pre-existing functions in already linked in ICU
library During the prototype phrase we identify no small size increase
impact since all the strings were already included to support other Chrome
functionality. Activation Web developers could use the API immediately upon
our shipment. Security Web developers could use the API immediately upon
our shipment.
Debuggability Nothing special. Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)? Yes It will be supported on all platform. Is this feature fully
tested by web-platform-tests

? Yes Tests were added into test262 before shipping it in chrome. Tracking
bug https://bugs.chromium.org/p/v8/issues/detail?id=8703 Link to entry on
the Chrome Platform Status
https://www.chromestatus.com/feature/4965112605573120
This intent message was generated by Chrome Platform Status
.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8S-wQiUw6WXMp9VN5A%2BwKVCHvtv%3DHJd8WE7OS%3D%2B7Bqnw%40mail.gmail.com.

[v8-users] Re: [blink-dev] Re: Intend to Ship: Add calendar options/patterns and other calendars

[Frank Tang]

Sorry, I forgot to remove "Note that since this is a V8/JS feature, this
post is just an FYI to blink-dev — no signoff from Blink API owners is
required." when I copy and paste from my old I2S email. It should be

"

Requesting approval to ship?

Yes.

"

On Thu, Oct 3, 2019 at 1:06 PM Chris Harrelson 
wrote:

> Also, v8 intents do in fact go through the Blink API owners process.
> Please don't ship until there are 3 LGTMs.
>
> LGTM1
>
> On Thu, Oct 3, 2019 at 12:40 PM Frank Tang  wrote:
>
>> To clarify these 3 PRs are considered by both ECMA402 subcommittee and
>> TC39 as "Stage 3"
>>
>> I forgot to include the previous "Intend to Implement" link. Here it is.
>>
>>
>> https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/numberingSystem%7Csort:date/blink-dev/HFOWIjSBKWQ/XZnslmWsAQAJ
>>
>> These three PRs was once only 1 PR and later got split into 3 PRs. so the
>> original I2I cover all of them.
>>
>>
>> On Wed, Oct 2, 2019 at 1:11 PM Frank Tang  wrote:
>>
>>> These three ECMA402 PRs are intertwined and need to be considered to
>>> ship together instead of three different one:
>>>
>>> #175 Add calendar and numberingSystem options
>>> #349 Allow calendar to determine choice of pattern
>>> #351 Permit relatedYear and yearName in output
>>>
>>>
>>> Spec
>>>
>>> https://github.com/tc39/ecma402/pull/175
>>>
>>> https://github.com/tc39/ecma402/pull/349
>>>
>>> https://github.com/tc39/ecma402/pull/351
>>>
>>> Summary
>>>
>>>
>>> All three ECMA402 PRs reach consensus from both ECMA402 committee late
>>> Sept and TC39 in Oct. These three PRs make the pre-existing
>>> Intl.DateTimeFormat to specify different "calendar" via option (instead of
>>> appending the calendar as "-u-ca-$calendar"  in locale) and make the
>>> Intl.DateTimeFormat choose the pattern accordingly. It also change the
>>> formatToParts method to output "relatedYear" or "yearName" type for some
>>> non-gregorian calendar (such as Chinese calendar) while both the Chinese
>>> calendar year name and the gregorian year name are displayed based on the
>>> pattern.
>>>
>>> It also let Intl.DateTimeFormat and Intl.NumberFormat take
>>> numberingSystem from options (instead of appending "-u-nu-$numberingSystem"
>>> in locale).
>>> Example
>>>
>>> let o = new Intl.DateTimeFormat("en" , {
>>>   calendar: "chinese", year: "numeric"
>>> });console.log(o.format(Date.now())); // 
>>> "2019(ji-hai)"console.log(o.formatToParts(Date.now()));
>>> // [{type: "relatedYear", value: "2019"},
>>> //  {type: "literal", value: "("},
>>> //  {type: "yearName", value: "ji-hai"},
>>> //  {type: "literal", value: ")"}]
>>>
>>> let n = new Intl.NumberFormat("en" , {
>>>   numberingSystem: "thai"
>>> });console.log(n.format(1234567890)); // "๑๒๓,๔๕๖,๗๘๙"
>>>
>>>
>>>
>>> Interoperability and compatibility risk
>>>
>>> The options "numberingSystem" added to Intl.DateTimeFormat and
>>> Intl.NumberFormat is already supported by Intl.Locale and
>>> Intl.RelativeTimeFormat with the same meaning. The options "calendar" added
>>> to Intl.DateTimeFormat is already supported by Intl.Locale with the same
>>> meaning. The risk to break pre-existing javascript code is low.
>>>
>>>-
>>>
>>>Firefox: No public signals
>>>-
>>>
>>>Edge: No public signals
>>>-
>>>
>>>Safari:No public signals
>>>-
>>>
>>>Web Developers:No signals
>>>
>>>
>>> Is this feature fully tested?
>>>
>>> Yes; our implementation passes our own V8 tests for all the features.
>>>
>>> test/intl/number-format/check-numbering-system.js
>>> test/intl/number-format/constructor-numberingSytem-order.js
>>> test/intl/date-format/check-numbering-system.js
>>> test/intl/date-format/check-calendar.js
>>> test/intl/date-format/constructor-calendar-numberingSytem-order.js
>>> test/intl/date-format/related-year.js
>>> test/intl/regress-9786.js
>>> test/intl/regress-9787.js
>>> test

[v8-users] Re: Intend to Ship: Add calendar options/patterns and other calendars

[Frank Tang]

To clarify these 3 PRs are considered by both ECMA402 subcommittee and TC39
as "Stage 3"

I forgot to include the previous "Intend to Implement" link. Here it is.

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/numberingSystem%7Csort:date/blink-dev/HFOWIjSBKWQ/XZnslmWsAQAJ

These three PRs was once only 1 PR and later got split into 3 PRs. so the
original I2I cover all of them.


On Wed, Oct 2, 2019 at 1:11 PM Frank Tang  wrote:

> These three ECMA402 PRs are intertwined and need to be considered to ship
> together instead of three different one:
>
> #175 Add calendar and numberingSystem options
> #349 Allow calendar to determine choice of pattern
> #351 Permit relatedYear and yearName in output
>
>
> Spec
>
> https://github.com/tc39/ecma402/pull/175
>
> https://github.com/tc39/ecma402/pull/349
>
> https://github.com/tc39/ecma402/pull/351
>
> Summary
>
>
> All three ECMA402 PRs reach consensus from both ECMA402 committee late Sept 
> and
> TC39 in Oct. These three PRs make the pre-existing Intl.DateTimeFormat to
> specify different "calendar" via option (instead of appending the calendar
> as "-u-ca-$calendar"  in locale) and make the Intl.DateTimeFormat choose
> the pattern accordingly. It also change the formatToParts method to
> output "relatedYear" or "yearName" type for some non-gregorian calendar
> (such as Chinese calendar) while both the Chinese calendar year name and
> the gregorian year name are displayed based on the pattern.
>
> It also let Intl.DateTimeFormat and Intl.NumberFormat take numberingSystem
> from options (instead of appending "-u-nu-$numberingSystem" in locale).
> Example
>
> let o = new Intl.DateTimeFormat("en" , {
>   calendar: "chinese", year: "numeric"
> });console.log(o.format(Date.now())); // 
> "2019(ji-hai)"console.log(o.formatToParts(Date.now()));
> // [{type: "relatedYear", value: "2019"},
> //  {type: "literal", value: "("},
> //  {type: "yearName", value: "ji-hai"},
> //  {type: "literal", value: ")"}]
>
> let n = new Intl.NumberFormat("en" , {
>   numberingSystem: "thai"
> });console.log(n.format(1234567890)); // "๑๒๓,๔๕๖,๗๘๙"
>
>
>
> Interoperability and compatibility risk
>
> The options "numberingSystem" added to Intl.DateTimeFormat and
> Intl.NumberFormat is already supported by Intl.Locale and
> Intl.RelativeTimeFormat with the same meaning. The options "calendar" added
> to Intl.DateTimeFormat is already supported by Intl.Locale with the same
> meaning. The risk to break pre-existing javascript code is low.
>
>-
>
>Firefox: No public signals
>-
>
>Edge: No public signals
>-
>
>Safari:No public signals
>-
>
>Web Developers:No signals
>
>
> Is this feature fully tested?
>
> Yes; our implementation passes our own V8 tests for all the features.
>
> test/intl/number-format/check-numbering-system.js
> test/intl/number-format/constructor-numberingSytem-order.js
> test/intl/date-format/check-numbering-system.js
> test/intl/date-format/check-calendar.js
> test/intl/date-format/constructor-calendar-numberingSytem-order.js
> test/intl/date-format/related-year.js
> test/intl/regress-9786.js
> test/intl/regress-9787.js
> test/intl/regress-9788.js
> test/intl/regress-966285.js
>
> Also test262 tests (more to come this week #2379
> <https://github.com/tc39/test262/pull/2379> #2381
> <https://github.com/tc39/test262/pull/2381> #2383
> <https://github.com/tc39/test262/pull/2383>)
> intl402/NumberFormat/numbering-system-options
> intl402/DateTimeFormat/numbering-system-calendar-options
>
>
> Tracking bug
>
> https://crbug.com/v8/9154
>
> https://crbug.com/v8/9155
>
>
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/features/5440249461211136
>
>
>
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8iJdVbwNWBhdU-1HiNVqp4pQm_C1CfrF6D%3DHvWWPdN9w%40mail.gmail.com.

[v8-users] Intend to Ship: Add calendar options/patterns and other calendars

[Frank Tang]

These three ECMA402 PRs are intertwined and need to be considered to ship
together instead of three different one:

#175 Add calendar and numberingSystem options
#349 Allow calendar to determine choice of pattern
#351 Permit relatedYear and yearName in output


Spec

https://github.com/tc39/ecma402/pull/175

https://github.com/tc39/ecma402/pull/349

https://github.com/tc39/ecma402/pull/351

Summary


All three ECMA402 PRs reach consensus from both ECMA402 committee late Sept and
TC39 in Oct. These three PRs make the pre-existing Intl.DateTimeFormat to
specify different "calendar" via option (instead of appending the calendar
as "-u-ca-$calendar"  in locale) and make the Intl.DateTimeFormat choose
the pattern accordingly. It also change the formatToParts method to
output "relatedYear" or "yearName" type for some non-gregorian calendar
(such as Chinese calendar) while both the Chinese calendar year name and
the gregorian year name are displayed based on the pattern.

It also let Intl.DateTimeFormat and Intl.NumberFormat take numberingSystem
from options (instead of appending "-u-nu-$numberingSystem" in locale).
Example

let o = new Intl.DateTimeFormat("en" , {
  calendar: "chinese", year: "numeric"
});console.log(o.format(Date.now())); //
"2019(ji-hai)"console.log(o.formatToParts(Date.now()));
// [{type: "relatedYear", value: "2019"},
//  {type: "literal", value: "("},
//  {type: "yearName", value: "ji-hai"},
//  {type: "literal", value: ")"}]

let n = new Intl.NumberFormat("en" , {
  numberingSystem: "thai"
});console.log(n.format(1234567890)); // "๑๒๓,๔๕๖,๗๘๙"



Interoperability and compatibility risk

The options "numberingSystem" added to Intl.DateTimeFormat and
Intl.NumberFormat is already supported by Intl.Locale and
Intl.RelativeTimeFormat with the same meaning. The options "calendar" added
to Intl.DateTimeFormat is already supported by Intl.Locale with the same
meaning. The risk to break pre-existing javascript code is low.

   -

   Firefox: No public signals
   -

   Edge: No public signals
   -

   Safari:No public signals
   -

   Web Developers:No signals


Is this feature fully tested?

Yes; our implementation passes our own V8 tests for all the features.

test/intl/number-format/check-numbering-system.js
test/intl/number-format/constructor-numberingSytem-order.js
test/intl/date-format/check-numbering-system.js
test/intl/date-format/check-calendar.js
test/intl/date-format/constructor-calendar-numberingSytem-order.js
test/intl/date-format/related-year.js
test/intl/regress-9786.js
test/intl/regress-9787.js
test/intl/regress-9788.js
test/intl/regress-966285.js

Also test262 tests (more to come this week #2379
 #2381
 #2383
)
intl402/NumberFormat/numbering-system-options
intl402/DateTimeFormat/numbering-system-calendar-options


Tracking bug

https://crbug.com/v8/9154

https://crbug.com/v8/9155



Link to entry on the Chrome Platform Status dashboard

https://www.chromestatus.com/features/5440249461211136




Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL_8Syp%2B21ZtM_%3Di2B1e%2B_CXaASUYfuTFh17i7xn995rYQ%40mail.gmail.com.

Re: [v8-users] Re: [blink-dev] Intent to Implement and Ship: Let all early errors be SyntaxErrors

[Frank Tang]

Is this feature controlled by a flag.
I try to roll test262 and got a lot of errors related to this now.

On Wed, Jun 19, 2019 at 12:07 PM Adam Klein  wrote:

> Hi Yoav,
>
> We don't have existing metrics that would help here, and I honestly don't
> even know what we would track for this specific issue (detecting that a
> certain exception came from eval, for example, isn't something we currently
> track).
>
> Bug reports are how we tend to track issues like this. And fwiw my
> intuition matches Sathya & Ross's (that this is very unlikely to cause
> problems in practice).
>
> On Mon, Jun 17, 2019 at 9:42 PM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> Do we have metrics in place in case we got it wrong and sites do rely on
>> eval's error types in weird and unexpected ways? Or we're relying on bug
>> reports to alert us of that?
>>
>> On Tue, Jun 18, 2019 at 6:34 AM Chris Harrelson 
>> wrote:
>>
>>> I see. Given that lack of interop, I do agree that probably sites are
>>> not relying on the current behavior, and if they are then they are likely
>>> not interoperable.
>>>
>>> LGTM1 to try.
>>>
>>> On Mon, Jun 17, 2019 at 3:02 PM Ross Kirsling 
>>> wrote:
>>>


 On Mon, Jun 17, 2019, 11:42 Chris Harrelson 
 wrote:

> Hi again,
>
> Sorry for the slow response.
>
> On Thu, Jun 6, 2019 at 7:17 AM Sathya Gunasekaran <
> gsat...@chromium.org> wrote:
>
>>
>> I don't expect to see code that special cases against ReferenceError
>> in the wild especially for just early errors. I expect to see code
>> that handles both ReferenceErrors and SyntaxErrors. Since we're not
>> adding a new type of error, I wouldn't expect to see any breakage.
>>
>
> Do you have any data to support this? Are there any use counters for
> how often this situation might occur? e.g. what fraction of pages
> trigger ReferenceErrors?
> Also, have any other browsers shipped this change yet?
>

 The concern here is purely around *early* ReferenceError. Since
 ReferenceError has been ambiguous between parse time and runtime, it would
 have been extremely difficult/fragile to use this information—as mentioned,
 one would need to string-match on error messages. (I think folks are hung
 up on the phrase "observable concern", but I meant this to indicate that
 there's something non-cosmetic to be *gained*, not that there's worry about
 breakage.)

 The new behavior shipped in Safari TP 83 three weeks ago, and it's
 important to note that the major engines were not previously in alignment
 anyway. V8 was conforming to spec, but JSC actually had *late*
 ReferenceError for all four cases and SM was split (`0++` and `0--` were
 early SyntaxError while `0 = 0` and `0 += 0` were early ReferenceError).

 --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQtWJoxxi3PwfutmSbZFJGyNkKpgD1OeMFDM6%3D2sA4bw%40mail.gmail.com
>> 
>> .
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CAEvLGcKV93MirncPshaX9z29%3D5-0aBcecEOJ-Z%3D0zZE1%2BQb%3D7w%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL9fxhx1eXDQ9Cyauru9zwCgOUT5DnrCAGFAtM9GMkjZaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to Implement: Add quarter option for Intl.DateTimeFormat

[Frank Tang]

On Wed, May 22, 2019 at 3:33 PM Frank Tang  wrote:

> Contact emails ft...@chromium.org,js...@chromium.org Explainer
> https://github.com/tc39/ecma402/pull/345
>

Adam suggested I add an explainer, here you go
shorturl.at/aeoq1

Design docs/spec https://github.com/tc39/ecma402/pull/345 TAG review Discus
> under ECMA402 / TC39. No need for TAG Review. Summary Add quarter option
> to Intl.DateTimeFormat so the caller can format date such as "Q2 2019",
> "3rd quarter 2019" (or in Chinese as "2019年第2季") Motivation It enhance
> the Intl.DateTimeFormat API to match what the developer cal already do in
> C++ and Java by calling ICU and ICU4J. Without this feature, developer need
> to either format the quarter in the server or ship a set of quarter and
> date pattern from the server to client to perform such task. Risks
> Interoperability and Compatibility Low. *Firefox*: No public signals
> *Edge*: No public signals *Safari*: No public signals *Web developers*:
> No signals Ergonomics All the data are already build into chrome already
> as part of the date time format pattern. Won't increase data size.
> Activation Uses can use pre-existing Intl.DateTimeFormat plus this new
> option. Security low.
> Debuggability no specific need. Will this feature be supported on all six
> Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
> WebView)? Yes Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ? Yes Tests will be added into test262 before consider shipping. Link to
> entry on the Chrome Platform Status
> https://www.chromestatus.com/features/4678198379937792
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL-E-S5Np-L5NBcU_U5fYZwR8TuH6-f%2BroqYe_y4osrbcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Implement: Add dayPeriod option for Intl.DateTimeFormat

[Frank Tang]

Contact emails ft...@chromium.org,js...@chromium.org Explainer
https://github.com/tc39/ecma402/pull/346 Design docs/spec Specification:
https://github.com/tc39/ecma402/pull/346
https://github.com/tc39/ecma402/pull/346 TAG review No TAG review needed
since it is part of TC39 ECMA402 Summary Add dayPeriod option to
Intl.DateTimeFormat so the caller can format time such as "7 in the
morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the
evening", "10 at night" (or in Chinese "清晨7時", "上午11時", "中午12時", "下午1時"
,"下午6時" ,"晚上10時") Motivation It enhances the Intl.DateTimeFormat API to
match what the developer cal already do in C++ and Java by calling ICU and
ICU4J. Without this feature, developer need to either format the quarter in
the server or ship a set of day period pattern and hour to day period
mapping logic from the server to client to perform such task. Risks
Interoperability and Compatibility low. *Firefox*: No public signals *Edge*:
No public signals *Safari*: No public signals *Web developers*: No signals
Ergonomics No increase of data. All required data already build into ICU.
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully
tested by web-platform-tests

? Yes Tests will be added into test262 before we consider shipping it. Link
to entry on the Chrome Platform Status
https://www.chromestatus.com/features/6520669959356416

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL_E1OqHa87m0Wd00x9KMZjD5t4sTLF9qtuCZHBx1bGz5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Implement: Add quarter option for Intl.DateTimeFormat

[Frank Tang]

Contact emails ft...@chromium.org,js...@chromium.org Explainer
https://github.com/tc39/ecma402/pull/345 Design docs/spec
https://github.com/tc39/ecma402/pull/345 TAG review Discus under ECMA402 /
TC39. No need for TAG Review. Summary Add quarter option to
Intl.DateTimeFormat so the caller can format date such as "Q2 2019", "3rd
quarter 2019" (or in Chinese as "2019年第2季") Motivation It enhance the
Intl.DateTimeFormat API to match what the developer cal already do in C++
and Java by calling ICU and ICU4J. Without this feature, developer need to
either format the quarter in the server or ship a set of quarter and date
pattern from the server to client to perform such task. Risks
Interoperability and Compatibility Low. *Firefox*: No public signals *Edge*:
No public signals *Safari*: No public signals *Web developers*: No signals
Ergonomics All the data are already build into chrome already as part of
the date time format pattern. Won't increase data size. Activation Uses can
use pre-existing Intl.DateTimeFormat plus this new option. Security low.
Debuggability no specific need. Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)? Yes Is this feature fully tested by web-platform-tests

? Yes Tests will be added into test262 before consider shipping. Link to
entry on the Chrome Platform Status
https://www.chromestatus.com/features/4678198379937792

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL96APSbhjVmQ%2B-uthYX%3DB4c8t7qJQOxJGJJ5w0ddiPe7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Implement: Intl.NumberFormat Unified API Proposal

[Frank Tang]

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




Contact emails

ft...@chromium.com, s...@chromium.com

Explainer

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

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

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



Design doc/Spec

https://goo.gl/ZAtL1f

Summary

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

Motivation

There are many requests for adding number-formatting-related features to
ECMA-402 for Intl.NumberFormat. These features are important to both end
users and to websites. Since most of these features require carrying along
large amounts of locale data for proper i18n support, exposing these
features via a JavaScript API reduces bandwidth and lowers the barrier to
entry for i18n best practices.

Rather than complicate Intl with more constructors with heavily overlapping
functionality, this proposal is to restructure the spec of
Intl.NumberFormat to make it more easily support additional features in a
"unified" way.


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.

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.

Debuggability

Nothing special.



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

Yes.

Is this feature fully tested by web-platform-tests

?

Tests under tc39/test262 will includes many tests to test this API. Under
test262/tree/master/test/intl402/NumberFormat


Link to entry on the feature dashboard 

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

Requesting approval to ship?

“No”. The feature is behind a runtime flag
harmony_unified_intl_numberformat and
I will later send an Intent to Ship

email when I am ready to enable by default.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL9%3Dc1CE5DD8K9K5nHC-JERy5S7WZmO%2Bt7eoxyhvPJoMFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal

[Frank Tang]

Sorry, I am not quite sure what you mean. It seems to me a suggestion of
proposing additional standard in HTML spec. Do you mind to raise the issue
in https://github.com/tc39/proposal-intl-displaynames/issues with more
information so other members in ECMA402 subcommittee can help me to take
action to talk to the related parties?

Thanks

On Mon, May 13, 2019 at 10:41 PM PhistucK  wrote:

> I wonder whether this should be accompanied by an HTML equivalent
> declarative way of displaying those strings, otherwise the HTML strings
> might be left blank or JavaScript will be required for filling up what
> could sometimes be simple forms that were simply internationalized.
> Pseudo-code example -
> 
>  State/province:
>  
> 
>
>
> ☆*PhistucK*
>
>
> On Tue, May 14, 2019 at 5:03 AM Frank Tang  wrote:
>
>>
>>
>> On Mon, May 13, 2019 at 6:56 PM 'Frank Tang (譚永鋒)' via v8-dev <
>> v8-...@googlegroups.com> wrote:
>>
>>>
>>>
>>> *From: *Mathias Bynens 
>>> *Date: *Mon, 13 May 2019 at 18:08
>>> *To: *Frank Tang
>>> *Cc: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>>> Gunasekaran, Nebojša Ćirić, , Jungshik Shin,
>>> Shane Carr
>>>
>>> Can the doc at https://goo.gl/im9wy4 be made public please?
>>>>
>>>
>>> It always is.
>>>
>>
>> sorry it was not. I got confused since I shared with my other account. It
>> is now.
>>
>>>
>>>
>>>>
>>>> Usually we only implement features at stage 3. What’s the motivation
>>>> for implementing this particular API earlier? (Not saying I’m opposed to
>>>> it.)
>>>>
>>>
>>> Since I am the champion of the proposal itself, having a prototype
>>> implementation help me to figure out some tricky issues in the
>>> specification level. In specific, tricky issues about speed, memory and
>>> size that might be avoid if I specify differently. Sometime these thing
>>> won't be obvious until implementation. Of course, we can wait till stage 3
>>> then implement it, and then if we find out tricky issues which will
>>> increase binary size or cause latency problem, we will have to go back to
>>> request to change the specification.
>>>
>>>
>>>
>>>> *From: *Frank Tang 
>>>> *Date: *Mon, May 13, 2019 at 9:43 PM
>>>> *To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>>>> Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
>>>> Jungshik Shin, Shane Carr
>>>>
>>>> Title: Intent to Implement: Intl.DisplayNames API Proposal
>>>>>
>>>>>
>>>>>
>>>>> Contact emails
>>>>>
>>>>> ft...@chromium.com
>>>>>
>>>>>
>>>>>
>>>>> Explainer
>>>>>
>>>>> https://github.com/tc39/proposal-intl-displaynames
>>>>>
>>>>> https://tc39.github.io/proposal-intl-displaynames/
>>>>>
>>>>>
>>>>> Design doc/Spec
>>>>>
>>>>> Engineering Plan https://goo.gl/im9wy4
>>>>>
>>>>>
>>>>> Summary
>>>>>
>>>>> Provides a new API to get localized names of language, region, script,
>>>>> currency codes of international standard as well as commonly used names of
>>>>> date fields and symbols.
>>>>>
>>>>>
>>>>> Motivation
>>>>>
>>>>> Main motivation for Intl.DisplayNames project was to enable developers
>>>>> to get translation of language, region or script display names on the
>>>>> client. Translation of languages, regions or script display names requires
>>>>> large amount of data to transmit on the network, which is already 
>>>>> available
>>>>> in most browsers. These display name translations also carry steep data
>>>>> size penalty for developers. This API will allow web developers to shrink
>>>>> the size of their HTML and/ or ECMAScript code without the need to include
>>>>> the human readable form of display names and therefore reduce the download
>>>>> size to decrease latency. Also, this API will reduce the localization cost
>>>>> for the web developers. Our goal is to expose this data through Intl API
>>>>> for use in e.g. language, region and script pickers, etc.
>>>>>
>>>&g

[v8-users] Intent to Implement: "numberingSystem" option for Intl.NumberFormat / "calendar" and "numberingSystem" option for Intl.DateTimeFormat

[Frank Tang]

Contact emails ft...@chromium.org,js...@chromium.org Explainer
https://github.com/tc39/ecma402/pull/175 Design docs/spec Specification:
https://github.com/tc39/ecma402/pull/175
https://github.com/tc39/ecma402/pull/175 TAG review No need for TAG review
since the TC39 / ECMA402 process provide oversight. Summary Allows calendar
and numberingSystem to be specified in the options bag of the
DateTimeFormat and NumberFormat constructors. Motivation One use case for
these options would be, when working with locales which have two numbering
systems and calendars in use--the UA default may be the non-Western one,
but in some contexts, it may be appropriate to use the Western one.
Currently, without the patch, it would be necessary to parse the BCP 47
language tag in the application. This feature make it simpler for the
developer. See https://github.com/tc39/ecma402/pull/175 for more details.
Risks
Interoperability and Compatibility The PR in
https://github.com/tc39/ecma402/pull/175 is in last stage to be merged into
ECMA402. *Firefox*: No public signals *Edge*: No public signals *Safari*:
No public signals *Web developers*: No signals Ergonomics Small. Both Intl
object already provide the underline format functionality by reading
calendar ("ca") and numberingSystem ("nu") from the locale. This feature
only add a tiny option reading step Activation Low. A lot of users already
use these two API . New Javascript code which follow this change running on
an old version of browser which does not support this browser will format
the number and/or date in different result. But users should still be able
to understand these output. Security None
Debuggability No additional debugging support required. Will this feature
be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS,
Android, and Android WebView)? Yes Is this feature fully tested by
web-platform-tests

? Yes Tests will be added to test262 before launching Link to entry on the
Chrome Platform Status
https://www.chromestatus.com/features/5440249461211136

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL_AamuY_jQBmqQjLUW7rswNNih3AQ2SxJ%2BG8CP4r%2Bn9GQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal

[Frank Tang]

On Mon, May 13, 2019 at 6:56 PM 'Frank Tang (譚永鋒)' via v8-dev <
v8-...@googlegroups.com> wrote:

>
>
> *From: *Mathias Bynens 
> *Date: *Mon, 13 May 2019 at 18:08
> *To: *Frank Tang
> *Cc: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
> Gunasekaran, Nebojša Ćirić, , Jungshik Shin,
> Shane Carr
>
> Can the doc at https://goo.gl/im9wy4 be made public please?
>>
>
> It always is.
>

sorry it was not. I got confused since I shared with my other account. It
is now.

>
>
>>
>> Usually we only implement features at stage 3. What’s the motivation for
>> implementing this particular API earlier? (Not saying I’m opposed to it.)
>>
>
> Since I am the champion of the proposal itself, having a prototype
> implementation help me to figure out some tricky issues in the
> specification level. In specific, tricky issues about speed, memory and
> size that might be avoid if I specify differently. Sometime these thing
> won't be obvious until implementation. Of course, we can wait till stage 3
> then implement it, and then if we find out tricky issues which will
> increase binary size or cause latency problem, we will have to go back to
> request to change the specification.
>
>
>
>> *From: *Frank Tang 
>> *Date: *Mon, May 13, 2019 at 9:43 PM
>> *To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>> Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
>> Jungshik Shin, Shane Carr
>>
>> Title: Intent to Implement: Intl.DisplayNames API Proposal
>>>
>>>
>>>
>>> Contact emails
>>>
>>> ft...@chromium.com
>>>
>>>
>>>
>>> Explainer
>>>
>>> https://github.com/tc39/proposal-intl-displaynames
>>>
>>> https://tc39.github.io/proposal-intl-displaynames/
>>>
>>>
>>> Design doc/Spec
>>>
>>> Engineering Plan https://goo.gl/im9wy4
>>>
>>>
>>> Summary
>>>
>>> Provides a new API to get localized names of language, region, script,
>>> currency codes of international standard as well as commonly used names of
>>> date fields and symbols.
>>>
>>>
>>> Motivation
>>>
>>> Main motivation for Intl.DisplayNames project was to enable developers
>>> to get translation of language, region or script display names on the
>>> client. Translation of languages, regions or script display names requires
>>> large amount of data to transmit on the network, which is already available
>>> in most browsers. These display name translations also carry steep data
>>> size penalty for developers. This API will allow web developers to shrink
>>> the size of their HTML and/ or ECMAScript code without the need to include
>>> the human readable form of display names and therefore reduce the download
>>> size to decrease latency. Also, this API will reduce the localization cost
>>> for the web developers. Our goal is to expose this data through Intl API
>>> for use in e.g. language, region and script pickers, etc.
>>>
>>>
>>> Benefit
>>>
>>>-
>>>
>>>Reduce download size of apps and therefore improve latency.
>>>-
>>>
>>>Easy for users to build internationalized language, region or script
>>>selection UI components (drop down menu or other kinds).
>>>-
>>>
>>>Reduce translation cost for developers.
>>>-
>>>
>>>Consistent translation of language, region and script display name
>>>on the web.
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new API. It is currently under TC39 Stage 1 and we plan to
>>> propose to advance it to Stage 2 in June 2019.
>>>
>>>
>>> Ergonomics
>>>
>>>
>>> Activation
>>>
>>> Web developers could use the API immediately upon our shipment.
>>>
>>>
>>> Debuggability
>>>
>>> Nothing special.
>>>
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>> ?
>>>
>>> Tes

[v8-users] Intent to Implement: Intl.DisplayNames API Proposal

[Frank Tang]

Title: Intent to Implement: Intl.DisplayNames API Proposal



Contact emails

ft...@chromium.com



Explainer

https://github.com/tc39/proposal-intl-displaynames

https://tc39.github.io/proposal-intl-displaynames/


Design doc/Spec

Engineering Plan https://goo.gl/im9wy4


Summary

Provides a new API to get localized names of language, region, script,
currency codes of international standard as well as commonly used names of
date fields and symbols.


Motivation

Main motivation for Intl.DisplayNames project was to enable developers to
get translation of language, region or script display names on the client.
Translation of languages, regions or script display names requires large
amount of data to transmit on the network, which is already available in
most browsers. These display name translations also carry steep data size
penalty for developers. This API will allow web developers to shrink the
size of their HTML and/ or ECMAScript code without the need to include the
human readable form of display names and therefore reduce the download size
to decrease latency. Also, this API will reduce the localization cost for
the web developers. Our goal is to expose this data through Intl API for
use in e.g. language, region and script pickers, etc.


Benefit

   -

   Reduce download size of apps and therefore improve latency.
   -

   Easy for users to build internationalized language, region or script
   selection UI components (drop down menu or other kinds).
   -

   Reduce translation cost for developers.
   -

   Consistent translation of language, region and script display name on
   the web.


Risks

Interoperability and Compatibility

This is a new API. It is currently under TC39 Stage 1 and we plan to
propose to advance it to Stage 2 in June 2019.


Ergonomics


Activation

Web developers could use the API immediately upon our shipment.


Debuggability

Nothing special.



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

Yes.


Is this feature fully tested by web-platform-tests

?

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


Link to entry on the feature dashboard 

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


Requesting approval to ship?

“No”. The feature is behind a runtime flag harmony_intl_display_names and I
will later send an Intent to Ship

email when I am ready to enable by default.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL-oXxvg5OgbukD54YfT9h0QcURtbTXnM7XSrzxDz3tPYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to Ship: Add formatRange / formatRangeToParts to DateTimeFormat

[Frank Tang]

to: blink-api-owners-disc...@chromium.org



On Thu, May 9, 2019 at 8:22 PM Frank Tang  wrote:

> Intend to ship for Chrome m76
>
>
> Title: Intent to Ship: Add formatRange / formatRangeToParts to
> DateTimeFormat
>
>
> Contact emails
>
> ft...@chromium.com, fabal...@chromium.com
>
> Explainer
>
> https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange
>
>
> https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
>  (notice
> the spec is already advanced into stage 3 in tc39 March 2019 meeting but
> the latest version has not bump the version from 2 to 3 yet)
>
>
> Spec
>
>
> https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
>
> Design Doc https://goo.gl/PGUQ1d
> 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
> <https://tc39.github.io/process-document/>.
>
>
>
> Summary
>
> Add two new functions to Intl.DateTimeFormat.prototype - formateRange and
> formatRangeToParts to formate the range of two dates in a given locale.
>
>
> Link to “Intent to Implement” blink-dev discussion
>
>
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/DateTimeFormat%7Csort:date/blink-dev/WTAjjcXaraA/osqw0lCpBAAJ
>
>
>
> 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-intl-DateTimeFormat-formatRange
>
>
> Debuggability
>
> Nothing special.
>
>
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API which agreed in TC39 meeting as a Stage 3 proposal.
> Engineer from Firefox team is supporting this proposal and the development
> is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1496584
>
>
> Ergonomics
>
> The performance of constructing the Intl.DateTimeFormat could be slower if
> we create the underline icu DateIntervalFormatter. To avoid such
> performance issue we identified, currently we plan to lazy initialize the
> required DateIntervalFormatter upon the first call to the formatRange or
> formateRangeToParts and cache the value afterward. This approach avoid such
> performance impact.
>
>
> Activation
>
> Web developers could use the API immediately upon our shipment, based on
> the usage of previous well supported Intl.DateTimeFormat object.
>
>
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
> Link to test suite results from wpt.fyi.
>
>
> Tests under tc39/test262 will includes many tests to test this API.
>
> test/intl402/DateTimeFormat/prototype/formatRange
> <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRange>
> and
>
> test/intl402/DateTimeFormat/prototype/formatRangeToParts
> <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRangeToParts>
>
>
> Testing Status (since the feature is currently behind a flag, the
> breakage, which does not include the flag turning on is high. Once shipped,
> with the flag turn on by default, the passing rate will turn to 100%)
> https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRange
>
> https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRangeToParts
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
> https://www.chromestatus.com/feature/5077134515109888
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL8YQJXzJ_g%2BFKskAsFmGjWExziQ0%2Btp1STn%2BQ9zMbabrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Ship: Add formatRange / formatRangeToParts to DateTimeFormat

[Frank Tang]

Intend to ship for Chrome m76


Title: Intent to Ship: Add formatRange / formatRangeToParts to
DateTimeFormat


Contact emails

ft...@chromium.com, fabal...@chromium.com

Explainer

https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange

https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
(notice
the spec is already advanced into stage 3 in tc39 March 2019 meeting but
the latest version has not bump the version from 2 to 3 yet)


Spec

https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/

Design Doc https://goo.gl/PGUQ1d
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

Add two new functions to Intl.DateTimeFormat.prototype - formateRange and
formatRangeToParts to formate the range of two dates in a given locale.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/DateTimeFormat%7Csort:date/blink-dev/WTAjjcXaraA/osqw0lCpBAAJ



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-intl-DateTimeFormat-formatRange


Debuggability

Nothing special.



Risks

Interoperability and Compatibility

This is a new API which agreed in TC39 meeting as a Stage 3 proposal.
Engineer from Firefox team is supporting this proposal and the development
is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1496584


Ergonomics

The performance of constructing the Intl.DateTimeFormat could be slower if
we create the underline icu DateIntervalFormatter. To avoid such
performance issue we identified, currently we plan to lazy initialize the
required DateIntervalFormatter upon the first call to the formatRange or
formateRangeToParts and cache the value afterward. This approach avoid such
performance impact.


Activation

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



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


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

test/intl402/DateTimeFormat/prototype/formatRange

and

test/intl402/DateTimeFormat/prototype/formatRangeToParts



Testing Status (since the feature is currently behind a flag, the breakage,
which does not include the flag turning on is high. Once shipped, with the
flag turn on by default, the passing rate will turn to 100%)
https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRange
https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRangeToParts

Entry on the feature dashboard 
https://www.chromestatus.com/feature/5077134515109888

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL9mCNtM745fqWcVMwv1_JNZD0t7z%3DzDihbMiziOLHwOUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow Intl.NumberFormat format/formatToParts to take BigInt

[Frank Tang]

Sorry, correction here for my incorrect "example". It should be

I made some mistake in my copy/paste

Example

12345678901234567890n.toLocaleString("de")
// "12.345.678.901.234.567.890"

12345678901234567890n.toLocaleString("en")

// "12,345,678,901,234,567,890"

12345678901234567890n.toLocaleString("hi")

// "1,23,45,67,89,01,23,45,67,890"

12345678901234567890n.toLocaleString("fa")

// "۱۲٬۳۴۵٬۶۷۸٬۹۰۱٬۲۳۴٬۵۶۷٬۸۹۰"

12345678901234567890n.toLocaleString("fr")

// "12 345 678 901 234 567 890"

12345678901234567890n.toLocaleString("th-Thai")

// "12,345,678,901,234,567,890"

12345678901234567890n.toLocaleString("th-u-nu-Thai")

// "๑๒,๓๔๕,๖๗๘,๙๐๑,๒๓๔,๕๖๗,๘๙๐"

let nf = new Intl.NumberFormat("hi");

nf.format(12345678901234567890n);

// "1,23,45,67,89,01,23,45,67,890"

nf.formatToParts(12345678901234567890n);

// [{type: "integer", value: "1"},
//  {type: "group", value: ","},
//  {type: "integer", value: "23"},
//  {type: "group", value: ","}
//  {type: "integer", value: "45"},
//  {type: "group", value: ","},
//  {type: "integer", value: "67"},
//  {type: "group", value: ","},
//  {type: "integer", value: "89"},
//  {type: "group", value: ","},
//  {type: "integer", value: "01"},
//  {type: "group", value: ","},
//  {type: "integer", value: "23"},
//  {type: "group", value: ","},
//  {type: "integer", value: "45"},
//  {type: "group", value: ","},
//  {type: "integer", value: "67"},
//  {type: "group", value: ","},
//  {type: "integer", value: "890"}]



On Thu, Apr 18, 2019 at 4:22 PM Adam Klein  wrote:

> LGTM2
>
> On Thu, Apr 18, 2019 at 4:21 PM Sathya Gunasekaran 
> wrote:
>
>> LGTM
>>
>> On Thu, Apr 18, 2019 at 4:02 PM Frank Tang  wrote:
>>
>>> *Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString &
>>> allow Intl.NumberFormat format/formatToParts to take BigInt*
>>>
>>>
>>> Spec
>>>
>>> https://github.com/tc39/ecma402/pull/236
>>>
>>>
>>> Summary
>>>
>>> A Stage 3 Pull Request to change the ECMA402 that support locale
>>> sensitive BigInt.prototype.toLocaleString to format the BigInt and also
>>> allow Intl.NumberFormat.prototype.format and
>>> Intl.NumberFormat.prototype.formatToParts to take BigInt as value.
>>> Example
>>>
>>> BigInt(12345678901234567890).toLocaleString("de")
>>> // "12.345.678.901.234.567.168"
>>>
>>> 12345678901234567890n.toLocaleString("en")
>>>
>>> // "12,345,678,901,234,567,168"
>>>
>>> 12345678901234567890n.toLocaleString("hi")
>>>
>>> // "1,23,45,67,89,01,23,45,67,168"
>>>
>>> 12345678901234567890n.toLocaleString("fa")
>>>
>>> // "۱۲٬۳۴۵٬۶۷۸٬۹۰۱٬۲۳۴٬۵۶۷٬۱۶۸"
>>>
>>> 12345678901234567890n.toLocaleString("fr")
>>>
>>> // "12 345 678 901 234 567 168"
>>>
>>> 12345678901234567890n.toLocaleString("th-Thai")
>>>
>>> // "12,345,678,901,234,567,168"
>>>
>>> 12345678901234567890n.toLocaleString("th-u-nu-Thai")
>>>
>>> // "๑๒,๓๔๕,๖๗๘,๙๐๑,๒๓๔,๕๖๗,๑๖๘"
>>>
>>> let nf = new Intl.NumberFormat("hi");
>>>
>>> nf.format(12345678901234567890n);
>>>
>>> // "1,23,45,67,89,01,23,45,67,168"
>>>
>>> nf.formatToParts(12345678901234567890n);
>>>
>>> // [{type: "integer", value: "1"},
>>> //  {type: "group", value: ","},
>>> //  {type: "integer", value: "23"},
>>> //  {type: "group", value: ","}
>>> //  {type: "integer", value: "45"},
>>> //  {type: "group", value: ","},
>>> //  {type: "integer", value: "67"},
>>> //  {type: "group", value: ","},
>>> //  {type: "integer", value: "89"},
>>> //  {type: "group", value: ","},
>>> //  {type: "integer", value: "01"},
>>> /

[v8-users] Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow Intl.NumberFormat format/formatToParts to take BigInt

[Frank Tang]

*Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow
Intl.NumberFormat format/formatToParts to take BigInt*


Spec

https://github.com/tc39/ecma402/pull/236


Summary

A Stage 3 Pull Request to change the ECMA402 that support locale sensitive
BigInt.prototype.toLocaleString to format the BigInt and also allow
Intl.NumberFormat.prototype.format and
Intl.NumberFormat.prototype.formatToParts to take BigInt as value.
Example

BigInt(12345678901234567890).toLocaleString("de")
// "12.345.678.901.234.567.168"

12345678901234567890n.toLocaleString("en")

// "12,345,678,901,234,567,168"

12345678901234567890n.toLocaleString("hi")

// "1,23,45,67,89,01,23,45,67,168"

12345678901234567890n.toLocaleString("fa")

// "۱۲٬۳۴۵٬۶۷۸٬۹۰۱٬۲۳۴٬۵۶۷٬۱۶۸"

12345678901234567890n.toLocaleString("fr")

// "12 345 678 901 234 567 168"

12345678901234567890n.toLocaleString("th-Thai")

// "12,345,678,901,234,567,168"

12345678901234567890n.toLocaleString("th-u-nu-Thai")

// "๑๒,๓๔๕,๖๗๘,๙๐๑,๒๓๔,๕๖๗,๑๖๘"

let nf = new Intl.NumberFormat("hi");

nf.format(12345678901234567890n);

// "1,23,45,67,89,01,23,45,67,168"

nf.formatToParts(12345678901234567890n);

// [{type: "integer", value: "1"},
//  {type: "group", value: ","},
//  {type: "integer", value: "23"},
//  {type: "group", value: ","}
//  {type: "integer", value: "45"},
//  {type: "group", value: ","},
//  {type: "integer", value: "67"},
//  {type: "group", value: ","},
//  {type: "integer", value: "89"},
//  {type: "group", value: ","},
//  {type: "integer", value: "01"},
//  {type: "group", value: ","},
//  {type: "integer", value: "23"},
//  {type: "group", value: ","},
//  {type: "integer", value: "45"},
//  {type: "group", value: ","},
//  {type: "integer", value: "67"},
//  {type: "group", value: ","},
//  {type: "integer", value: "890"}]

Interoperability and compatibility risk

The BigInt.prototype.toLocaleString was implemented as
BigInt.prototype.toString. This launch will make it return string
differently, based on the cultural conventions of the locale. Code
expecting the BigInt.prototype.toLocaleString behavior the same as
BigInt.prototype.toString will break but the chance is very low since the
ECMA262 specification already make it clear the toLocaleString is
delegating to the ECMA402 specification to specify. The
Intl.NumberFormat.prototype.format and formatToParts now take BigInt as
value instead of throwing exception.



   -

   Firefox:No public signals
   -

   Edge: No public signals
   -

   Safari:No public signals
   -

   Web Developers:No signals


Is this feature fully tested?

Yes; our implementation passes our own V8 tests for all the features as
well as tests under test262.

   -

   intl402/BigInt/prototype/toLocaleString
   

   -

   test/intl/bigint/
   


Tracking bug

https://crbug.com/v8/8699



Design Doc:

https://goo.gl/qpRwFo



Link to entry on the Chrome Platform Status dashboard

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

Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: DateTimeFormat dateStyle & timeStyle options

[Frank Tang]

so now the m75 branch off. Any one willing to second the shipping
of DateTimeFormat dateStyle & timeStyle options?

On Thu, Apr 11, 2019 at 4:02 PM Frank Tang  wrote:

> Since that missed the April 5 m75 Feature Freeze day and we are a week
> away from the April 18 m75 branch off date, I intend to move that to ship
> for m76 and land the cl of moving to ship around April 20, after the
> branching.
>
> On Thu, Apr 11, 2019 at 3:53 PM Sathya Gunasekaran 
> wrote:
>
>> LGTM
>>
>> On Mon, Apr 1, 2019 at 12:13 PM Sathya Gunasekaran 
>> wrote:
>>
>>>
>>>
>>> On Fri, Mar 29, 2019 at 7:41 AM Frank Tang  wrote:
>>>
>>>> Spec
>>>>
>>>> https://github.com/tc39/proposal-intl-datetime-style/
>>>>
>>>> Summary
>>>>
>>>> A Stage 3 proposal that adds two options to Intl.DateTimeFormat:
>>>> dateStyle and timeStyle. These options give a compact way to request the
>>>> appropriate, locale-specific way to ask for a date and time of given 
>>>> lengths
>>>> Example
>>>>
>>>> let o = new Intl.DateTimeFormat("en" , {
>>>>   timeStyle: "short"
>>>> });console.log(o.format(Date.now())); // "13:31"
>>>> let o = new Intl.DateTimeFormat("en" , {
>>>>   dateStyle: "short"
>>>> });console.log(o.format(Date.now())); // "21.03.2012"
>>>> let o = new Intl.DateTimeFormat("en" , {
>>>>   timeStyle: "medium",
>>>>   dateStyle: "short"
>>>> });console.log(o.format(Date.now())); // "21.03.2012, 13:31"
>>>>
>>>>
>>>>
>>>> Interoperability and compatibility risk
>>>>
>>>> The two new options added to Intl.DateTimeFormat is new and should have
>>>> no risk to break pre-existing javascript code.
>>>>
>>>>-
>>>>
>>>>Firefox:Public support
>>>><https://bugzilla.mozilla.org/show_bug.cgi?id=1329904>
>>>>-
>>>>
>>>>Edge: No public signals
>>>>-
>>>>
>>>>Safari:No public signals
>>>>-
>>>>
>>>>Web Developers:No signals
>>>>
>>>>
>>>> Is this feature fully tested?
>>>>
>>>> Yes; our implementation passes our own V8 tests for all the features.
>>>>
>>>> test/intl/date-format/constructor-date-time-style.js
>>>> test/intl/date-format/constructor-date-time-style-order.js
>>>> test/intl/date-format/property-override-date-time-style.js
>>>> test/intl/date-format/constructor-date-style-order.js
>>>> test/intl/date-format/property-override-date-style.js
>>>> test/intl/date-format/constructor-time-style-order.js
>>>> test/intl/date-format/property-override-time-style.js
>>>>
>>>>
>>> What about test262 tests?
>>>
>>
>> Test262 tests for this has landed and V8 passes all of them:
>>
>> https://chromium.googlesource.com/v8/v8/+/96c1a8835f04859fccf1d183c0f545cab7affe1d#
>>
>>
>>>
>>>
>>>> Tracking bug
>>>>
>>>> https://crbug.com/v8/8702
>>>>
>>>>
>>>> Design Doc:
>>>>
>>>> https://goo.gl/v7n7zV
>>>>
>>>>
>>>> Link to entry on the Chrome Platform Status dashboard
>>>>
>>>> https://www.chromestatus.com/features/5091631933947904
>>>>
>>>>
>>>>
>>>> Requesting approval to ship?
>>>>
>>>> Yes. Note that since this is a V8/JS feature, this post is just an FYI
>>>> to blink-dev — no signoff from Blink API owners is required.
>>>>
>>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: DateTimeFormat dateStyle & timeStyle options

[Frank Tang]

Since that missed the April 5 m75 Feature Freeze day and we are a week away
from the April 18 m75 branch off date, I intend to move that to ship for
m76 and land the cl of moving to ship around April 20, after the branching.

On Thu, Apr 11, 2019 at 3:53 PM Sathya Gunasekaran 
wrote:

> LGTM
>
> On Mon, Apr 1, 2019 at 12:13 PM Sathya Gunasekaran 
> wrote:
>
>>
>>
>> On Fri, Mar 29, 2019 at 7:41 AM Frank Tang  wrote:
>>
>>> Spec
>>>
>>> https://github.com/tc39/proposal-intl-datetime-style/
>>>
>>> Summary
>>>
>>> A Stage 3 proposal that adds two options to Intl.DateTimeFormat:
>>> dateStyle and timeStyle. These options give a compact way to request the
>>> appropriate, locale-specific way to ask for a date and time of given lengths
>>> Example
>>>
>>> let o = new Intl.DateTimeFormat("en" , {
>>>   timeStyle: "short"
>>> });console.log(o.format(Date.now())); // "13:31"
>>> let o = new Intl.DateTimeFormat("en" , {
>>>   dateStyle: "short"
>>> });console.log(o.format(Date.now())); // "21.03.2012"
>>> let o = new Intl.DateTimeFormat("en" , {
>>>   timeStyle: "medium",
>>>   dateStyle: "short"
>>> });console.log(o.format(Date.now())); // "21.03.2012, 13:31"
>>>
>>>
>>>
>>> Interoperability and compatibility risk
>>>
>>> The two new options added to Intl.DateTimeFormat is new and should have
>>> no risk to break pre-existing javascript code.
>>>
>>>-
>>>
>>>Firefox:Public support
>>><https://bugzilla.mozilla.org/show_bug.cgi?id=1329904>
>>>-
>>>
>>>Edge: No public signals
>>>-
>>>
>>>Safari:No public signals
>>>-
>>>
>>>Web Developers:No signals
>>>
>>>
>>> Is this feature fully tested?
>>>
>>> Yes; our implementation passes our own V8 tests for all the features.
>>>
>>> test/intl/date-format/constructor-date-time-style.js
>>> test/intl/date-format/constructor-date-time-style-order.js
>>> test/intl/date-format/property-override-date-time-style.js
>>> test/intl/date-format/constructor-date-style-order.js
>>> test/intl/date-format/property-override-date-style.js
>>> test/intl/date-format/constructor-time-style-order.js
>>> test/intl/date-format/property-override-time-style.js
>>>
>>>
>> What about test262 tests?
>>
>
> Test262 tests for this has landed and V8 passes all of them:
>
> https://chromium.googlesource.com/v8/v8/+/96c1a8835f04859fccf1d183c0f545cab7affe1d#
>
>
>>
>>
>>> Tracking bug
>>>
>>> https://crbug.com/v8/8702
>>>
>>>
>>> Design Doc:
>>>
>>> https://goo.gl/v7n7zV
>>>
>>>
>>> Link to entry on the Chrome Platform Status dashboard
>>>
>>> https://www.chromestatus.com/features/5091631933947904
>>>
>>>
>>>
>>> Requesting approval to ship?
>>>
>>> Yes. Note that since this is a V8/JS feature, this post is just an FYI
>>> to blink-dev — no signoff from Blink API owners is required.
>>>
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intend to Ship: DateTimeFormat dateStyle & timeStyle options

[Frank Tang]

Spec

https://github.com/tc39/proposal-intl-datetime-style/

Summary

A Stage 3 proposal that adds two options to Intl.DateTimeFormat: dateStyle
and timeStyle. These options give a compact way to request the appropriate,
locale-specific way to ask for a date and time of given lengths
Example

let o = new Intl.DateTimeFormat("en" , {
  timeStyle: "short"
});console.log(o.format(Date.now())); // "13:31"
let o = new Intl.DateTimeFormat("en" , {
  dateStyle: "short"
});console.log(o.format(Date.now())); // "21.03.2012"
let o = new Intl.DateTimeFormat("en" , {
  timeStyle: "medium",
  dateStyle: "short"
});console.log(o.format(Date.now())); // "21.03.2012, 13:31"



Interoperability and compatibility risk

The two new options added to Intl.DateTimeFormat is new and should have no
risk to break pre-existing javascript code.

   -

   Firefox:Public support
   
   -

   Edge: No public signals
   -

   Safari:No public signals
   -

   Web Developers:No signals


Is this feature fully tested?

Yes; our implementation passes our own V8 tests for all the features.

test/intl/date-format/constructor-date-time-style.js
test/intl/date-format/constructor-date-time-style-order.js
test/intl/date-format/property-override-date-time-style.js
test/intl/date-format/constructor-date-style-order.js
test/intl/date-format/property-override-date-style.js
test/intl/date-format/constructor-time-style-order.js
test/intl/date-format/property-override-time-style.js

Tracking bug

https://crbug.com/v8/8702


Design Doc:

https://goo.gl/v7n7zV


Link to entry on the Chrome Platform Status dashboard

https://www.chromestatus.com/features/5091631933947904



Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: Intl.Locale

[Frank Tang]

On Wed, Feb 20, 2019 at 11:42 AM Adam Klein  wrote:

> LGTM to ship, one note inline
>
> On Tue, Feb 19, 2019 at 9:59 PM Frank Tang (譚永鋒)  wrote:
>
>> Spec
>>
>> https://tc39.github.io/proposal-intl-locale/
>>
>> Summary
>>
>> A Stage 3 proposal that introduces a new standard built-in property of
>> the Intl object, which allows the following:
>>
>>-
>>
>>Parsing and manipulating the language, region and script of a locale
>>-
>>
>>Reading or writing the Unicode extension tags in a locale
>>-
>>
>>A serializable, standard format to store user locale preferences for
>>use in Intl APIs rather than a combination of language and options bag.
>>-
>>
>>For future proposals, a Locale class can be used for an interface to
>>get at various kinds of locale data, including likely subtags, first day 
>> of
>>the week, various display names, etc.
>>-
>>
>>Allow Intl objects to take Intl.Locale object as item in the locales
>>parameter in addition to the pre-existing string form.
>>
>> Example
>>
>> let loc = new Intl.Locale("pl-u-hc-h12", {
>>
>>  calendar: 'gregory'
>>
>> });
>>
>> console.log(loc.language); // "pl"
>>
>> console.log(loc.hourCycle); // "h12"
>>
>> console.log(loc.calendar); // "gregory"
>>
>> console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"
>>
>> // use Intl.Locale in Intl.DateTimeFormat constructor
>>
>> let df = new Intl.DateTimeFormat([loc, "pl"]);
>>
>> // Add likely subtags to the locale
>>
>> console.log(loc.maximize().toString()); //
>> "pl-Latn-PL-u-ca-gregory-hc-h12"
>>
>> // Remove likely subtags from locale
>>
>> console.log((new Intl.Locale("zh-Hant-TW")).minimize().toString()) //
>> "zh-TW"
>>
>> console.log((new Intl.Locale("zh-Hans-CN")).minimize().toString()) //
>> "zh"
>>
>>
>>
>> Interoperability and compatibility risk
>>
>> The Intl.Locale is new and should have no risk to break pre-existing
>> javascript code.
>>
>>-
>>
>>Firefox:In development
>><https://bugzilla.mozilla.org/show_bug.cgi?id=1433303>
>>-
>>
>>Edge:In development
>><https://github.com/Microsoft/ChakraCore/pull/5675>
>>-
>>
>>Safari:No public signals
>>-
>>
>>Web Developers:No signals
>>
>>
>> Is this feature fully tested?
>>
>> Yes; our implementation passes our own V8 tests as well as the Test262
>> tests for all the features. To pass all the test262 tests, V8 is based on
>> the latest ICU version 63 with 3 bug fixing patches (uloc1.patch
>> <https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc1.patch>,
>> uloc2.patch
>> <https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc2.patch>,
>> uloc3.patch
>> <https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc3.patch>),
>> which are part of the coming ICU 64 (schedule to be released on March 29,
>> 2019) release.
>>
>
> Based on our previous conversation, it sounds like even with ICU 63 the
> failures would only be in edge cases, i.e., very uncommon locales. Can you
> confirm?
>

YES. In my 30+ years involving software internationalization, I have not
seen a real system (beyond toy project from college homework) really use
these broken cases. The failure are on some uncommon locale ON some
additional edge cases. (not just uncommon locales)



>
>> Tracking bug
>>
>> https://crbug.com/v8/7684
>>
>>
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/4936310187884544
>>
>>
>>
>> Requesting approval to ship?
>>
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no signoff from Blink API owners is required.
>>
>>
>> --
>> Frank Yung-Fong Tang
>> 譚永鋒 / 
>> Sr. Software Engineer
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Fwd: [v8-dev] Intent to ship: Intl.Locale

[Frank Tang]

FYI-

My first attempt sent from ft...@google.com got bounced back. Trying to
forward from ft...@chromium.org.

Sorry for the DUP

-- Forwarded message -
From: 'Frank Tang (譚永鋒)' via v8-dev 
Date: Tue, Feb 19, 2019 at 9:59 PM
Subject: [v8-dev] Intent to ship: Intl.Locale
To: , , <
blink-...@chromium.org>
Cc: Sathya Gunasekaran , Adam Klein ,
Mathias Bynens , Nebojša Ćirić , Felipe
Balbontín , Shane Carr , Jungshik Shi
n (신정식, 申政湜) , Yang Guo 


Spec

https://tc39.github.io/proposal-intl-locale/

Summary

A Stage 3 proposal that introduces a new standard built-in property of the
Intl object, which allows the following:

   -

   Parsing and manipulating the language, region and script of a locale
   -

   Reading or writing the Unicode extension tags in a locale
   -

   A serializable, standard format to store user locale preferences for use
   in Intl APIs rather than a combination of language and options bag.
   -

   For future proposals, a Locale class can be used for an interface to get
   at various kinds of locale data, including likely subtags, first day of the
   week, various display names, etc.
   -

   Allow Intl objects to take Intl.Locale object as item in the locales
   parameter in addition to the pre-existing string form.

Example

let loc = new Intl.Locale("pl-u-hc-h12", {

 calendar: 'gregory'

});

console.log(loc.language); // "pl"

console.log(loc.hourCycle); // "h12"

console.log(loc.calendar); // "gregory"

console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"

// use Intl.Locale in Intl.DateTimeFormat constructor

let df = new Intl.DateTimeFormat([loc, "pl"]);

// Add likely subtags to the locale

console.log(loc.maximize().toString()); // "pl-Latn-PL-u-ca-gregory-hc-h12"

// Remove likely subtags from locale

console.log((new Intl.Locale("zh-Hant-TW")).minimize().toString()) //
"zh-TW"

console.log((new Intl.Locale("zh-Hans-CN")).minimize().toString()) // "zh"



Interoperability and compatibility risk

The Intl.Locale is new and should have no risk to break pre-existing
javascript code.

   -

   Firefox:In development
   <https://bugzilla.mozilla.org/show_bug.cgi?id=1433303>
   -

   Edge:In development <https://github.com/Microsoft/ChakraCore/pull/5675>
   -

   Safari:No public signals
   -

   Web Developers:No signals


Is this feature fully tested?

Yes; our implementation passes our own V8 tests as well as the Test262
tests for all the features. To pass all the test262 tests, V8 is based on
the latest ICU version 63 with 3 bug fixing patches (uloc1.patch
<https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc1.patch>,
uloc2.patch
<https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc2.patch>,
uloc3.patch
<https://cs.chromium.org/chromium/src/third_party/icu/patches/uloc3.patch>),
which are part of the coming ICU 64 (schedule to be released on March 29,
2019) release.

Tracking bug

https://crbug.com/v8/7684



Link to entry on the Chrome Platform Status dashboard

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



Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.


-- 
Frank Yung-Fong Tang
譚永鋒 / 
Sr. Software Engineer

-- 
-- 
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to ship: Intl.ListFormat

[Frank Tang]

Spec

https://tc39.github.io/proposal-intl-list-format

Summary

A Stage 3 proposal that introduces a new formatter under Intl.

Intl.ListFormat  helps libraries and frameworks format a list in a
localized fashion by providing internationalized messages using a customary
local word or phrase when available. For example, calling its format()
method with ["Alice", "Bob", "Charlie", "Delta"] would return the string
"Alice, Bob, Charlie and Delta" in English.
Example

let lf = new ListFormat("en");

lf.format(["Alice"]);

// > "Alicce"

lf.format(["Alice", "Bob"]);

// > "Alice and Bob"

lf.format(["Alice", "Bob", "Charlie"]);

// > "Alice, Bob and Charlie"

lf.format(["Alice", "Bob", "Charlie", "Delta"]);

// > "Alice, Bob, Charlie and Delta"

lf = new ListFormat("zh");

lf.format(["譚永鋒"]);

// > "譚永鋒"

lf.format(["譚永鋒", "劉新宇"]);

// > "譚永鋒和劉新宇"

Interoperability and compatibility risk

The Intl.ListFormat is new and should have no risk to break pre-existing
javascript code.

   -

   Firefox:In development
   -

   Edge:No public signals
   -

   Safari:No public signals
   -

   Web Developers: No public signals


Is this feature fully tested?

Yes; our implementation passes our own V8 tests as well as the Test262
tests for all the features.

Tracking bug

https://crbug.com/v8/7871

Link to entry on the Chrome Platform Status dashboard

https://www.chromestatus.com/features/4764538272481280

Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to ship: Intl.RelativeTimeFormat

[Frank Tang]

Spec

https://tc39.github.io/proposal-intl-relative-time/

Summary

A Stage 3 proposal that introduces a new formatter under Intl.

Intl.RelativeTimeFormat is a low level API to facilitate libraries and
frameworks to format relative time in a localized fashion by providing
internationalized messages for date and time fields, using customary word
or phrase when available.
Example

let rtf = new Intl.RelativeTimeFormat("en");
// Format relative time using the day unit.rtf.format(-1, "day");// >
"yesterday"
rtf.format(2.15, "day");// > "in 2.15 days"
rtf.format(100, "day");// > "in 100 days"
rtf.format(0, "day");// > "today"
rtf.format(-0, "day");// > "today"

// Format relative time using the day unit.rtf.formatToParts(-1,
"day");// > [{ type: "literal", value: "yesterday"}]
rtf.formatToParts(100, "day");// > [{ type: "literal", value: "in " },
{ type: "integer", value: "100", unit: "day" }, { type: "literal",
value: " days" }]

Interoperability and compatibility risk

The Intl.RelativeTimeFormat is new and should have no risk to break
pre-existing javascript code.

   - Firefox:In development
   - Edge:No public signals
   - Safari:No public signals
   - Web Developers:Positive


Is this feature fully tested?

Yes; our implementation passes our own V8 tests as well as the Test262
tests for all the features.

Tracking bug

https://crbug.com/v8/7869

Link to entry on the Chrome Platform Status dashboard

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

Requesting approval to ship?

Yes. Note that since this is a V8/JS feature, this post is just an FYI to
blink-dev — no signoff from Blink API owners is required.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.