On Fri, Aug 21, 2020 at 1:16 AM Ross Kirsling <[email protected]> wrote:
> > > On Fri, Aug 21, 2020 at 12:05 AM Frank Tang <[email protected]> wrote: > >> >> >> On Tue, Aug 18, 2020 at 1:33 AM Yoav Weiss <[email protected]> wrote: >> >>> >>> >>> On Tue, Aug 18, 2020 at 1:10 AM Frank Tang <[email protected]> wrote: >>> >>>> For m87 >>>> >>>> Contact [email protected], [email protected] >>>> >>>> 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 / [email protected] (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 >> 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. >> > I've heard this feature request from partners for two reasons: - It enables building full-text indexes e.g. using Indexed DB. WebSQL supported full text search (FTS) using its own engine, but browsers have removed that. FTS requires segmentation (this API) and optional stemming. Exposing ICU-equivalent segmentation saves developers from having to include that logic in their apps, or falling back to e.g. English-only segmentation and giving a poor experience in other locales. - More generally, we have requests from partners who implement custom text layout and rendering to canvas, e.g. as part of creative applications. Today, they are forced to ship ICU (or the equivalent) to support segmentation, e.g. using ICU built with WASM. Where possible, exposing web standard APIs that can be used instead will reduce the download cost users face. Non-API-OWNER opinion: The 0.4% number for use of Intl.v8BreakIterator seems high! An HTTP Archive analysis of how it's being used and the prospects for migrating that use to the standard API would be interesting (e.g. is it via a small number of actively maintained libraries?). But I have sufficient confidence in the utility of the segmenter API in general that I wouldn't block on such an analysis. > >> >>> >>>> >>>> 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 >>>> [email protected] >>>> 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 [email protected]. >>>> 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&utm_source=footer> >>>> . >>>> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/CACj%3DBEj62bfc0JA5rDhM%3Dci-2bOfPw0o7sHhATjvoNfVGsOi9g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/v8-dev/CACj%3DBEj62bfc0JA5rDhM%3Dci-2bOfPw0o7sHhATjvoNfVGsOi9g%40mail.gmail.com?utm_medium=email&utm_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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHnZyqDDH9gq5WxU3rtB1EEvKaQLunwqU2Hucyg8zM8H5uNMTg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHnZyqDDH9gq5WxU3rtB1EEvKaQLunwqU2Hucyg8zM8H5uNMTg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAD649j4dHr8_y3d4ziu4hcdes2x5VJmi5zTg0zinHcB0ec-c3g%40mail.gmail.com.
