- Shane Carr - Google i18n (SFC), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Craig Cornelius - Google i18n (CCN)
- Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison
- Corey Roy - Salesforce (CJR)
- Greg Tatum - Mozilla (GPT)
- Daniel Minor - Mozilla (DLM)
- Eemeli Aro - Mozilla (EAO)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Yusuke Suzuki - Apple (YSZ)
- Zibi Braniecki - Invited Expert (ZB)
- Myles C. Maxfield - Apple (MCM)
- Younies Mahmoud - Google i18n (YMD)
- Richard Gibson - OpenJS Foundation (RGN)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
USA: Happy ISO 2022 new year! Thank you RGN for amazing editorial work. The big changes are that we got DisplayNames v2 and TimeZone Names merged to the spec! Segmenter has been reviewed and it's just a matter of time until it gets merged. The important normative PR is the numbering system addition. The ListFormat PR is stalled; I hope to look at it by next meeting.
Presenter: RCA
- Runtime behaviour document - https://docs.google.com/document/d/1lCSg7H_Nz20_LITon3g12Iq5KtE9cxXTg58zyLeW3gw/edit originated by previous the discussion about Message Patterns https://www.google.com/url?q=https://github.com/unicode-org/message-format-wg/issues/212&sa=D&source=docs&ust=1642100404806359&usg=AOvVaw0P4Ojl-X0F1i8wM7UvfZrd
- Case Selection - https://docs.google.com/document/d/1nT-_-ZMknbtKvUc9lR9v9esOGiXK-OOPwJv7Ccl-2EI/edit#heading=h.6x3fflpb0yjs
- ECMA-402 Champions (EAO, DLM)
- Roadmap - https://github.com/unicode-org/message-format-wg/wiki/Roadmap-2022
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
RCA : Wiki is updated and major milestones are Intl. Segmenter MDN and Intl.DurationFormat drafts for test and MDN and NFv3 MDN
USA: The list of numbering systems in the spec is out of date. There is a new numbering system, "tsna". This PR is from Anba who wants to make sure we are in sync. There is a comment from JSC team asking us to wait. What’s the status ?
YSZ : We did not want to merge it until ICU shipped it.
FYT: ICU 70 has it.
YSZ : I think it is ok. It is in ICU now.
USA : We can merge this one
USA : Do you think this change would be helpful on the implementation side ? My concern it’s that Segmenter spec text does it’s not consist with other spec texts.
GPT: I think it's useful to have consistency in the spec text, but I don't have an opinion on this specific change.
USA: I'll just ask RGN to do what he thinks is best.
FYT : My preferences it’s to land whatever we have now, we are close to the publish deadline, and this is a minor editorial issue that we can address later. This change does only affects the location of the section not text itself
SFC : Ideally we should apply RGN's suggestion, but if we cannot make ECMA deadline the best it’s to keep as is
RGN: If we come to agreement on these changes, I can have a PR likely by the next plenary.
USA: I don't have strong opinions, and others don't have strong opinions, so I think you should make the PR.
EAO: It would be useful to have a document/contributing guideline to help you when writing the spec(Best practices etc …) ?
RGN: It has been a goal of mine to create just that since I started working on ECMA-402. The biggest obstacle is what aspects belong in the spec itself as opposed to adjacent to it. The idealized form of a section likely belongs in contributing guidelines.
SFC: We have a style guide .md where we can expand this documentation
Yes, RGN please make the proposed change, and then merge this into ES 2022.
tc39/proposal-intl-numberformat-v3#81
SFC: (introduces issue)
ICU change would be required to match the behavior here. demonstrates the issue
If we impose that mfd is required here, then we have the trailing zeroes. What I’m proposing is that we either require them to match or automatically set them in this case.
// Current Behavior:
{ maximumFractionDigits: 2, roundingIncrement: 5} // ==> 1.05, 1.1, ..., 1.95, 2
Proposed options:
- Require minimumFractionDigits = maximumFractionDigits, and throw exception if not
- Automatically set minimumFractionDigits = maximumFractionDigits
- Keep current spec behavior and block on ICU
FYT: I was convinced by SFC that my proposed solution isn’t good, but his proposal is better
GPT: It’s better to be more restricted now since we always have the option to relax it later.
EAO : Can we relax it later if we don’t require it ?
SFC: points out the options exceptions are the most forward compatible.I tend to Require and throw exception
RGN: I think I support this. I'm trying to remember if this is covered by the earlier discussion about the interaction on fraction and significant digits. But if we gate on the presence of the property, I support.
FYT: Can you repeat the proposal?
SFC: We throw if minimum != maximum, with no changes to the default setting of those options.
FYT: The default is 0 and you’re proposing that we throw, right?
SFC : OK?
GPT: +1 RCA : +1 EAO : +1
Shane’s proposal was accepted with full support.
tc39/proposal-intl-numberformat-v3#77
SFC: (introduces issue)
SFC: My preference is that we obey locale data and keep "min2" as a hint rather than a requirement.
GPT: If it's a hint, then "min2" is a developer request, but it's up to the translator data. If we require, then it's the developer who decides, rather than the locale data.
SFC : That’s correct
GPT: It seems like in the past, you want to have it be on the locale side. I'm unsure.
FYT: Hints suggest that locale may or may not have value , but in local model all the values has a resource fallback, writing this as an a hint , might never been use
SFC : If we have useGrouping = auto all fallback to use grouping separators , min2 instead fallback to the root will fallback to a min of 2 digits but some locales has more than 3 digits
FYT: If I have en-Deva-IN. If that has a value, but en-Deva has a different value, and en has a different value, which one do we obey? There are different levels of fallback.
SFC: There is no data for this, it’s a spec issue, once we find user preferences for that locale using those preferences , useGrouping overrides the lowest locale values in case local value is 1 we set it to 2. Other proposal it’s always set to two. I prefer set it to at least minimum 2.
FYT: Why we are changing this ? what’s the key motivation for this change ?
SFC : The motivation was when writing test262 was difficult to predict the behaviour to be more testable, I’m not asking for a change I’m trying to have consensus on this.
Should we change for the proposed behaviour or keep it as it is ?
SFC: Close the issue?
FYT: +1 EAO: +1 USA: +1
Close the issue.
tc39/proposal-intl-duration-format#90
FYT: (introduces issue)
USA: I’m not sure if this was change since we wrote it, I will look into the issue to check if expected behaviour or bug in spec
FYT: I think it's best to treat undefined values as 0.
USA: Yes, or we could make sure they are full duration objects, rather than records. Full duration objects of course have zeros instead of undefined.
USA: A few options:
- Fix the bug by treating undefined as 0
- Convert the option bag to a full Duration object
Go with option 1?
SFC: +1 ZB: +1 RCA: +1
Treat undefined as 0.
tc39/proposal-intl-duration-format#89
USA: (introduces issue)
FYT : I don’t understand in which condition we won’t be able to represent the day that way?
USA: Days are not always 24 hours long; they can be 23 or 25, which means it depends on where you count from.
FYT : We are talking about differences between daylight saving time ? same issue also apply to leap seconds
USA: Say you have a ZonedDateTime that starts before a daylight boundary. You have a duration that is 0.5 days. If you add that duration to it twice, you expect the exact same time one day after, but you don't get the exact same time. What if you take the same time and take the difference and divide by two? I think it would be confusing for arithmetic.
SFC : I think this issue about Day duration it’s a discussion that does not belong to this group , I think the correct discussion it’s about fractional minutes and hours. Regarding the actual stage of the proposal(3) we might have it included in a future V2 proposal with more time to investigate about.
USA: I agree that it's not the best idea to introduce this right now. The use cases are not strong enough to warrant it. I agree that we could do a draft PR to demonstrate how the spec text could be updated to allow it.
FYT: The question is whether this is intentional, or something we missed from the spec. I wanted to make sure it is by design. I'm okay leaving it the way it is, as long as we understand that it wasn't a mistake.
ZB via Chat: I agree with Ujjwal - if we already know we will want to be able to extend it before Stage 4 of Rev 1 we should POC how rev 2 would fit as a forward compatible extension of rev 1 before we progress with rev 1.
USA : This was intentional, done to match fractional sections display , I’m not opposed to the future expansion of the proposal but I don’t think we won’t have enough use cases where people keep track of time using fractional formats
EAO: "You have 2.5 minutes to complete this exercise."
SFC : I think there are use cases for it and I would like to see it included in future versions. Discussions around this issue are thorny, including (1) arithmetic behavior, (2) API shape, and (3) whether to stop at hours or also support days. I didn't want to block DurationFormat v1 on this issue, similar to how I didn't want Segmenter to be blocked on the line break issue. We should hold this discussions for DF v2. And perhaps that proposal will come soon.
USA: I like ZB’s idea, have a draft PR demonstrating possible changes on the spec that allow this feature to be included
EAO: Same opinion , it’s ok to proceed as is, but it’s good to have a possibility to enable that behaviour later
USA : I will try to come up with a spec text modification to demonstrate this possibility
https://github.com/tc39/test262/pull/3173/files
FYT : (introduces issue)
FYT: UTS35 accepts underscore as part of the locale ID, it’s part of the grammar. In BCP 47, underscores aren’t permitted
SFC: I think we should be as strict as possible. It's already most likely a user error when passing an invalid string, so we should throw an exception if something does not look like a calendar identifier.
FYT: This is V8 implementation behavior. I don't remember the spec behavior. I think the spec is not as strict as it should be.
SFC: Does anyone think that the behavior here is correct or does anyone think the string should be returned as a passthrough?
YSZ: Two things. (1) Whether the underscore is accepted as a syntax character, and (2) If we have a valid identifier but it doesn't exist in data. On (2), if an implementation has older data, for a valid identifier, we should not throw an error. But on (1), I think underscore is a bit ambiguous in the spec. If we don't allow underscore as a valid identifier in the syntax, we should throw an error for the underscore case. I'd also like to ensure that when using underscore for a language identifier, we throw an error; is it correct?
FYT : The current behaviour in V8 doesn’t match the spec , the second issue We didn’t have the second cluster for DisplayNames
SFC: I would like to YZS , USA and FYT to follow up offline to correct this
FYT : I can do a PR but this would be a normative PR
FYT: (introduces proposal)
MCM: Thanks for the presentation. I think it was quite helpful, because it made it clear to me that we agree more than we disagree. Much of your presentation was talking about how people want to do line breaking, and right now on non-Chrome browsers they don't have good options. The distinction I wanted to draw is one between having capabilities in the browser to perform line breaking and having this particular API standardized in this group. There could be many APIs that can produce line breaking; but there are other ways to do this. For example, content describes a boundary shape, and says to put text inside a boundary shape and see where the lines end up. Another would be an iterator type of API where the content would give strings to the browser and then the browser would give the runs back to the browser, with suggestions on where to wrap lines. It sounds like FYT is saying that unless we adopt this API, people can't do line breaking in the browser. But that is false; there are other ways to do it. The second point is that this API is not sufficient for solving all the use cases. They need to use fonts to measure text. This kind of api it’s the wrong level of abstraction, in order to do anything productive/value. I talked about houdini before , I don’t think that it’s the best technical answer but at least a good fit canvas-formatted-text could also be a good fit. That page says, "our goal is to create an abstraction that … collects strings into a data model." That sounds like exactly what the doctor ordered. We would prefer canvas-formatted-text rather than Houdini, and both are a much better fit than the JS standard library. I also want to push back on the fact that no reply has been posted in 4 weeks; in standards, 4 weeks is not a long time. As far as a potential effort in Houdini, we don't know what it would nbd up using (DOM, strings, etc); it's just that it would be in the right place in the software stack. Why have both API’s doing the same thing there's maintenance cost, and there's leading developers astray. Developers think they have the capabilities they need, but they actually need to look elsewhere for the rest of the tools. Finally, the WebKit team would formally object to move this proposal to Stage 2 in this standards group due to the aforementioned concerns
FYT : I have a question for YSZ. How about your group; are you in the Webkit group?
YSZ: I'm in the JSC group.
FYT: MCM says that WebKit opposes it; how about JSC?
YSZ: I’m also opposed to it , … I don’t think so because the Houdini and canvas-formatted-text doesn't have a lot of activity right now, but that doesn't mean we should do it in Intl instead. We should put it in the right place. And nothing prevents Node.js from implementing this API even if we define it in W3C; there are other examples of Node.js implementing Web APIs. Or Node.js can include it as a module. So Node.js is a weak motivation. As a result, I think we should define it in a more layout-related venue and spec rather than i18n.
SFC : Would be helpful to hear from someone from Mozilla or have more feedback from a non implementer
GPT: From Mozilla's perspective, we have some concerns over v8BreakIterator. I was trying to figure out where it's used; I think it's mostly used in the same charting library. I don't know how many web compat issues there are between Chrome and other browsers. But web compat is definitely a concern we have. As far as implementing the API, there is infra there; we can follow the same Intl.Segmenter code path to implement, but I do agree with Myles that there is an ongoing cost to maintaining it, and we should ensure that if we do it, that we do it in the right place. Would be beneficial if we do it. We should do it in the right place.
Another concern is on the presentation of the API. In my mind, I thought that this was where I could use the font and know where to put myu line breaks in. However, this is just iterating over the potential line breaking opportunities. So I think there is potential user confusion for line breaking versus potential line breaking. That might be a nitpick, but I think we need to ensure that people understand that additional information is required for this API to be useful. Another small nitpick is the monospace that is not always monospacing when use non latin characters.
SFC: On slide 14, there is a quote from Yegor listing a use case that is not tied directly to font rendering. Does anyone else have similar use cases?
MCM: I don't understand Yegor's concern. You still need font metrics to compute scrollable area.
RCA: A use case I've experienced in the past is when plain text comes from an API or server to represent terms and conditions. We want to arrange those line breaks in a useful way depending on the locale. Sometimes you have to figure out the layout. Normally, we provide HTML, but often the terms and conditions come in plain text due the reuse in different platforms and because they’re constantly changing(Banking accounts terms and conditions and Mortgage FINE document formats that are normative documents that must respect certain format)and we have to figure out how to render those assets.
SFC: Based on my limited personal experience, the problem of font rendering and layout is a much easier problem to solve in userland than the break iteration problem. There are small, fast, lightweight libraries to help with measuring font width, but not for line break segmentation.
FYT: (1) we are talking about a better place to do this, but currently, with v8BreakIterator, people are already using it for some things. We're trying to solve the current problem, not the "next" problem. (2) We already shipped Intl.Segmenter with word break. The natural thing people will do next is to misuse word break for line break, because there's nowhere else to segment it. But since Intl.Segmenter v1 has word break, they can use that rather than regular expressions: it mostly works for English text, and better than regex. (3) After three years, we haven't seen any movement in Houdini. I think Segmenter is an appropriate place for this functionality.
MCM: I got a few responses. I don't think that the level of abstraction of v8 breakiterator should be included in the specifications, The line breaking its a real use case, but I don’t think that split this in two use cases … the key there it’s the high level use cases are implemented first and low level cases are implemented based on the hierarchy of uses cases. Lastly, I wanted to push back on the urgency. v8BreakIterator has been shipping for 10 years. If there's no solution for another year, that's not a big problem. Saying that there's a deadline of 1 year seems entirely artificial.
FYT: In many cases, if people draw on canvas, that's it: they don't need multiline style. You can imagine what people will do, but in the limited use case, we don't need all the fancy stuff that comes after segmentation. For example, for the pie chart, v8BreakIterator satisfies their use case.
Intl.Segmenter wasn’t shipped before, now that we have this API people might miss using this API to do line break in a non correct way, but if you add Line break on this api people would have a good option to use a better choice. We were waiting for some activity about having a good solution to replace v8BreakIterator and has been 3 years without any feedback and with Segmenter API it’s an opportunity to have this in an achievable timeline
MCM: I think we disagree on what the next step is. Callers are going to call this API, and then the next step is to place text in a line. For the abuse situation, I think SFC gave an example of how people have been abusing line breaking for a decade. Just because we have word breaking doesn't mean that people are any more likely to abuse than they already are. Finally, posting an message and not seeing a response does not mean that the recipient of the message doesn't think it is a good idea.
SFC: In ECMA-402 we have a long list of issue that are pending, which we haven't been able to action simply because the issues come down to people and companies choosing to devote the time to make them happen.
SFC: I also want to take this opportunity to plug ICU4X as a short-term solution for line breaking on the web. It won’t be as good as a standards-based solution, of course, but we are providing developers a more lightweight API that they can ship with their app to perform this functionality.
FYT to incorporate the feedback and decide how to move forward.