Attendees:
- Shane Carr - Google i18n (SFC), Moderator
- Eemeli Aro - OpenJSF (EAO)
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Leo Balter - Salesforce (LEO)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Jeff Walden - Spidermonkey (JSW)
- Richard Gibson - OpenJSF and Oracle (RGN)
- Daniel Ehrenberg - Igalia (DE)
- Ujjwal Sharma - Igalia (USA)
- Myles C. Maxfield - Apple (MCM)
- Eemeli Aro (EAO)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
RCA: We had our 7th meeting this week. We are closing in on our goals and non-goals. I would like you to take a look at the pull request. We've been active lately. We have a new chair group that helps us with higher velocity. Next week we have a chair group meeting, where we plan to form next steps on what else we do this year.
Pull Request Goals and Non-Goals : unicode-org/message-format-wg#59 Pull Request Implementation Ideias: unicode-org/message-format-wg#85
RCA: I haven't had enough time to review all of the MDN issues. I would like to make it more dynamic: get more people involved. Some of our recent proposals deserve more attention and review. We stopped a few months ago on some of these documents, and I think we can do better. I'm asking if more people should contribute.
SFC: for clarification, we have the ECMA 402 listed issues, and I’ll paste a link to it.
https://github.com/tc39/ecma402-mdn/issues
SFC: There’s a number of issues regarding documentation listed on this repo. If you’re looking for good ways to contributions to ECMA 402, this is a great thing to help out with.
EAO: For the various options like formatters and so on, there's not a clear list about what browser and Node version each individual option is available. Is that list available, or do we need to add that to MDN?
DE: Right now in MDN, the documentation about options is a bit sparse, more option documentation and compat table data would be relevant. If anyone’s interested in writing those, we can get in touch with MDN maintainers about the format.
RCA: There was also some discussion within the MDN group on that. We sometimes do browser compat on APIs only. For new or experimental properties, we add compat data, but that wasn't a standard thing. ONly when we added something new. I'm not sure when we added that with styling on Intl.NumberFormat(Intl.DateTimeFormat instead). So it's been on a case-by-case basis.
The options where added to Intl.DateTimeFormat for timeStyle and dateStyle PR
SFC: at one point last summer, we had a smaller meeting with the MDN folks and I think it’s both an exciting and important piece of work to be involved in. Perhaps I should start an email thread on this list and have more discussion about this particular topic.
JSW: explains GitHub thread The current wording is a little confusing and that’s mentioned in #425. This PR also seeks to fix that. Right now, there are contradictions between the different requirements, and this seeks to fix that.
SFC: the correct syntax is UTS 35. There was another issue that was opened about this duplicate variant issue. The whole “let’s sort and de-dup” variants is dependent on UTS-35, so it makes sense to make that a little explicit. What you propose seems reasonable to me. We should use this pattern everywhere we need these language tags.
JSW: it’s not precisely de-duplication.
SFC: how does your pull request relate to BCP-47 and UTS-35 conformance?
JSW: The upstream specs don't specify what should happen with "structurally valid" in source and target languages. So this is going a step farther.
SFC: I think this would be a great thing to get some feedback from Mark Davis and ZB. Mark is the author of the spec and the two were having a discussion about it. I'm happy with this PR, but from a spec perspective, it makes sense to get a review from someone outside our group.
FYT: I’m lost. There’s one line here that says that it doesn’t contain “unicode variant subtag”? Does that mean you cannot have unicode or just one particular case?
JSW: You can't have duplicate variants on a top-level language tag.
FYT: not what I’m asking. quotes line 53 from PR When I read this, it sounds like it shouldn't have the Unicode subvariant. Line 53 is confusing.
JSW: This is where the no-duplicate clause is invoked.
FYT: On line 53, it sounds to me like you shouldn't have the variant there.
JSW: “doesn’t contain equivalent…” I could add “duplicated”.
SFC: that’s an editorial issue. FYT, could you leave a comment about it?
FYT: How I read it is that “it shouldn’t have any variants”.
SFC: Do we want to record consensus before Mark’s review? There’s important changes that we should get feedback about, and once that’s done, we can get a RSLGTM from this body. Sounds good?
JSW: SGTM
FYT: Basically, ECMA 402 has a section about numbering systems and the language in 402 says “these are the things in the standard but browsers are allowed to use extra systems”. This comes from CLDR, but some number systems are harder to use. I wrote a hacky script to try this out in browsers. Mozilla doesn't support everything I proposed, but I wonder why, because ICU makes it easy to support these. There are two numbering systems that were newly added in ICU, which Safari and V8 support.
JSW: is it necessarily a good idea to mention all of these systems explicitly in the spec? Is it a big maintenance burden?
FYT: I added to the list because the table already existed.
SFC: In some cases we have a list, but sometimes it is impl dependent. It’s always spec compliant for browsers to support systems that aren’t on this list.
FYT: if we don’t change this, browsers can stop supporting it. If there’s already several browsers supporting, then there’s no harm in adding this, is it?
SFC: I guess the meta-question is: there’s three ways we do it. For calendars, we leave up to impls, For Number systems, we have a minimal list, and for measurement, we have an exhaustive list. Where should we draw the line? Any thoughts?
MCM: If a browser supports a numbering system outside of the core set, is it well-specified how it behaves?
SFC: “Else use an implementation dependent algorithm to map n to the appropriate representation of n in the given numbering system.” No, it’s not well-specified, it’s implementation dependent.
MCM: it’s an anti-pattern on the web, because minority browsers need to reverse-engineer what the dominant browser does.
SFC: I think that argument has some merit.
FYT: This PR says explicitly how it should behave.
SFC: do we want to go a step further and say that more numbering systems are disallowed.
MCM: That's usually how the listing of encodings works. The HTML spec says for character encodings what browsers should support, and says not to support any others.
FYT: There is no numbering system to support all cultures. So this is different from the encodings in HTML.
SFC: I guess that’s one way to draw a line. Talking about measurement units. It’s very awkward and it changes the meaning of the numbers if you support alternate measuring units. In this case, it just falls back to Latin so it is not that bad. Not to mention, it’s non-trivial to remove support for numbering systems.
MCM: that’s a fairly important responsibility of the browser to create a filter between native functionality and functionality on the web.
SFC: what I’m saying is that extra numbering systems are strictly nice-to-have.
MCM: Both sides of an if statement should be well-defined: what should happen if the browser does or does not support a feature.
SFC: would it be okay from your perspective if we strengthened the implementation dependent phrasing?
FYT: We have to be careful here. If we only look at the numbering systems here: how the whole locale is supported. Anything in 402 is browser-dependent. We don't limit the ECMA-402 implementation to support a well-defined set of locales. If we try to follow the model of listing things explicitly, we'd need to do that with locales.
DE: I think we have well-defined limits about where implementations may differ. I agree with MCM about browser compatibility and feature testing. We could let this happen and give browsers flexibility about which numbering systems they support. I wonder if that could pass this kind of test. I think there’s a lot of stuff in ECMA 402 which is strictly optional and a lot of it is probably okay, but in this case, it’s well-scoped to allow more numbering systems to be supported without such loose implementation-dependent phrasing. Does that make sense?
MCM: I don't know whether it makes sense or not.
SFC: Let’s get back to the topic. We already have the table and Frank is just adding to the table. Let’s keep the two discussions separate. Should we add these to the list?
MCM: Yes, that sounds like a good idea.
DE: I too agree.
SFC: the only downside is that it helps browsers who do not wish to support the full set might not agree with that assessment. Also, it opens a can of worms. Should we have a static list? Should we update this on a yearly cadence?
JSW: Anba said that ICU gives us support for these. There are some font-rendering concerns, but other than that, we are fine with adding more stuff here.
FYT: The rendering issue is separate.
MCM: You can install web fonts.
JSW: It's independent, but if you want to work with these numbers for formatting, you probably want to display them, too.
SFC: my ask is that if we approve the PR, we may document a best practice about how often we update the table of numbering systems. Should we do it periodically? Or in an Ad-hoc way like right now? Maybe after each new Unicode release? What if we updated the list as a part of editorial work ahead of the release of a new version of the spec?
MCM: seems reasonable to me.
FYT: to be honest, unless we already have a very clear playbook, it would be ad-hoc by default.
DE: we are doing a similar thing with respect to the Unicode version and MB does that in an ad-hoc way.
SFC: MB does it synced with the Unicode version?
FYT: that’s fine, but as you said, it’s ad-hoc. It’s too much of a burden if we add a process.
RGN: the update in the spec is just a very simple change. It’s more important to update the tests.
SFC: I’d be happy to keep it ad-hoc and we can define an (editorial) process to improve that.
SFC: Are there objections to approving this PR?
(silence)
Has Consensus
We also need to bring this up at TC39.
USA: (explains issue)
USA: As long as people can make dropdowns and such, I think it's okay for people advocating for such APIs.
SFC: FYT made a Stage 0 proposal about this, and does this group agree with this idea? Should we move ahead with this idea?
RCA: Yes
LEO: Yes
MCM: There are concerns about fingerprinting in general. I'd like to have a chance to discuss this with privacy experts at my company before signing off on this.
USA: We want to discuss use cases. Having them scattered around, with time zone in Temporal, number systems in Number, why not keep them in a single place where you can have a single solution to replace these APIs? That said, I'm happy with the idea of discussing further with security experts.
SFC: fingerprinting is discussed by ZB in detail in this thread. I would like to defer the question of fingerprinting to privacy experts. Does that need to be a Stage 1 blocker or is this a discussion that can be had later?
MCM: Can we just discuss this again next month?
LEO: I think this could be presented to TC39 in one way or another, and while I don’t want to make judgements about the fingerprinting…
SFC: it’s more relevant to present this to TC39 as a stage advancement.
RCA: The W3C feature people could affect the work being done on this side. We could have some collaboration regarding feature paralysis? They are working on privacy policies more related to the DOM, but they are doing work on the policy, too.(https://w3c.github.io/webappsec-feature-policy/)
FYT: I want to point out two things. First, I suggest we take off two things: script and region. Because the spec is very vague, and what does that really mean? So I suggest we remove those two. The second is that, I don't really understand the fingerprinting principle, but you can get the fingerprinting already from the browser by evaluating an exhaustive list. But ZB pointed out that it requires more computing power. I don't really understand that argument.
MCM: There's another argument; I don't know if it's been made. Browsers can detect if a website is calling a whole bunch of i18n functions, and they can stop and start returning random information. Enumeration makes it more difficult for a browser to do this.
LEO: Stage 1 says that we are investigating the problem space. We have an interest, we know a challenge.
SFC: I think this is a great example of something to investigate at Stage 1.
MCM: Okay, thanks for the link to the doc (https://tc39.es/process-document/). By that doc, it sounds like the fingerprinting concern can be done at Stage 1.
LEO: FYT would you like to add it to the agenda? The deadline is tomorrow.
SFC: It
LEO: Does anyone have objections for stage 1?
(silence)
Consensus for Stage 1
SFC: Is there anything else to discuss on this?
FYT: What do you think about some of the issues I raised? Removing script/region?
SFC: LGTM
FYT: I also made some polyfills. https://github.com/FrankYFTang/proposal-intl-enumeration/tree/master/polyfill
USA: Luxon (Moment.js) is doing something similar. Now it's just a nicer way to do it.
RCA: Do you have a reference, USA, to other polyfills to look at?
USA: We had some examples in Temporal. If you're looking at some use cases, I can use this API that Frank made.
RCA: I just want to compare Frank's implementation to what you already had.
USA: I'll send a link
SFC: We should triage the 402 issues.
JSW: Seems reasonable to me
SFC: Should I send out a calendar invitation? Who else is interested?
LEO: I'm interested
SFC: I'll send out a Doodle.
FYT: The default locale is 12 hours, and if we somehow turn on the 12-hour cycle, it will resolve to 24 hours by the current computation in the spec. Test262 is written that way. Originally, V8 is not implemented like that. When I jumped into this, I assume the details got nailed down. I tried my best to hack and pass the test, and then Anba said it doesn't make sense. So now he's proposing that we change it so that the return value will make more sense whenever that happens.
SFC: h24 is weird. Firefox's behavior is better.
SFC: Any objections to letting USA and FYT work on this?
(silence)
SFC: This changes the behavior of toString, like new Intl.NumberFormat().toString(). It's a normative change, but a good one.
LEO: Yes, it's a good change.
FYT: Segmenter proposal returns something weird, so maybe we should change that too.
RGN: I think I added those and I think that’s consistent with 402.
FYT: there’s three exact places where that happens.
RGN: it inherits “Object” from 402 and the iterator returns the space separated collation and that’s picked up from 262. I believe one of the iterators in 262 has one. Segment iterator prototype returns a toStringTag that’s unusual in 402 but makes sense in 262.
FYT: I think there's a regex string iterator. The regex string iterator prototype.
RGN: Yeah, I'll paste a link.
FYT: Overall, I guess I’ll just say that I agree with this change in behavior.
RGN: https://tc39.es/ecma262/#sec-%regexpstringiteratorprototype%-@@tostringtag … and the general "<Capitalized Noun Phrase> Iterator" pattern is visible with a search for “IteratorPrototype% [ @@toStringTag ]”
SFC: do we have consensus on this PR?
checking with other browser implementers
JSW: Yeah, this makes sense.
MCM: Fine with me.
SFC: I will record the consensus and let’s talk about it in TC39.
SFC: presents issue This would be a Normative change but I don’t believe it would be a harmful one.
JSW: It makes sense. If someone asks for a certain behavior, they should get that behavior.
SFC: Great, so I’ll leave this in the milestone to be worked on.
FYT: For things we already support in the API, I think it makes sense to do this.
SFC: The set of things that we're still missing is small, so I think it makes sense to complete it.
USA: +1
FYT: I volunteer to work on this.
SFC: Great!