ships the entire payload requirement #588
Assignees
Labels
Milestone
Comments
|
My interpretation here is that any valid data in any API must be present in the enumeration, and any data present in the enumeration must be valid in any API. |
|
CC @codehag Is the above discussion about shipping the entire payload actionable in the context of this proposal, or is it a general ECMA-402 issue that can be actioned separately? |
|
This is a general issue that can be actioned separately. |
|
Also filed #720 to clarify on this. Once we have agreement that the issue is beyond the scope of intl-enumeration, we could close that issue and file normative PRs to 402 against this. |
|
@iainireland clarified Mozilla's position on this issue in the 2021-07-13 TC39:
|
sffc
added
c: meta
sffc
added
s: help wanted
sffc
added a commit
that referenced
this issue
Sep 9, 2021
# 2021-09-09 ECMA-402 Meeting ## Logistics ### Attendees - Shane Carr - Google i18n (SFC), Co-Moderator - Corey Roy - Salesforce (CJR) - Romulo Cintra - Igalia (RCA), MessageFormat Working Group Liaison - Thomas Steiner - Google (TOM) - Frank Yung-Fong Tang - Google i18n, V8 (FYT) - Long Ho - (LHO) - Zibi Braniecki - Mozilla (ZB) - Eemeli Aro - Mozilla (EAO) - Greg Tatum - Mozilla (GPT) - Yusuke Suzuki - Apple (YSZ) - Louis-Aimé de Fouquières - Invited Expert (LAF) - Richard Gibson - OpenJS Foundation (RGN) - Myles C. Maxfield - Apple (MCM) ### Standing items - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! - [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) ## Status Updates ### Editor's Update RGN: No updates. ### MessageFormat Working Group RCA: We are working on a middle-ground data model that I hope will unblock the situation. EAO is focused on it, with Stas, Mihai, etc. EAO also put together an initial spec proposal. EAO: I put together a spec outline, not a specific proposal. I think we will be able to merge it later this week. ### Proposal Status Changes https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking FYT: Some more Test262 coverage is done. But we still need help. RCA: I updated browser compat for locale info, documentation for hour cycle, etc. FYT: Do we have an instruction guide about how to update MDN? RCA: The process is moving quickly. It will be easier, though: you can just edit a Markdown file. ## Pull Requests ### Add changes to Annex A Implementation Dependent Behaviour tc39/proposal-intl-locale-info#43 FYT: We added some changes to Appendix A. Does this look good? Do we have consensus to report this to TC39? SFC: +1 RGN: +1 LAF: +1 #### Conclusion Approved ### Change weekInfo to express non-continouse [sic] weekend tc39/proposal-intl-locale-info#44 FYT: Some regions have a non-contiguous weekend. This PR changes the data model to reflect that. LAF: I wonder how this should be understood for all countries. In certain countries, the two "out of business" days may be not contiguous. Should we call it business day and non business day? Because "weekend" might not be the correct terminology. SFC: Is there precedent in CLDR for using "business day" instead of "weekend"? EAO: A quick Google search suggests that Brunei calls these days "weekend". SFC: LAF, please open an issue on the repository to discuss the option name change. SFC: Do we have consensus on the change? LAF: +1 SFC: +1 #### Conclusion Approved ## Proposals and Discussion Topics ### CollationsOfLocale() order tc39/proposal-intl-locale-info#33 SFC: I feel that lists should define their sort order. This is similar to the plural rule strings discussion from a couple of months ago. ZB: I represent the other side. I think developers should not be depending on the order. LAF: (inaudible) RGN: There is guaranteed to be an observable order. The question is whether that order is enforced across implementations, and if so, what should that order be? FYT: Could we return a Set? RGN: Sets also have observable order. SFC: I propose we bring the meta question to TC39-TG1 as a change to the style guide. LAF: +1 about order issue FYT: OK #### Conclusion SFC to make a presentation to TC39-TG1 to establish a best practice in the style guide. ### Define if "ca" Unicode extensions have an effect on Intl.Locale.prototype.weekInfo tc39/proposal-intl-locale-info#30 LAF: My opinion about ISO-8601 is that it is not connected to any locale. Something like Gregorian is connected to a locale, and could carry week info. But ISO-8601 is international. SFC: I think we should consult with CLDR. FYT: This is about the first day of the week and minimal days in the week, not the weekend days. I personally believe that we shouldn't limit the extension; for example, a subdivision could have legislation to change this info. LAF: In my opinion, the impact of saying whether Sunday or Monday is the first day of week, or on the minimal days, is to make a "week calendar": a calendar that lays out days in a week, dated by week number. I can imagine that some countries would like to distribute their own calendar, but I feel that there is a need among people to have the same week numbers. I don't know for sure where the correct place for this concept is. ZB: This is inspired by the mozIntl API. The reason I needed it was for a general calendrical widget, the HTML picker. I think date pickers in general need this, not just calendar layout. I think it is a high-importance API. SFC: I think the calendar subtag, or other subtags like the subdivision, should be taken into account. FYT: I think we should take the whole locale to influence the result. FYT: Do we need to make any changes to the proposal, and if so, what changes are needed? RCA: No strong opinion on that, but concerned by the possible conflict with Temporal #### Conclusion SFC, FYT, and LAF agree that the whole locale (including extension subtags) should influence the weekInfo. FYT to share these notes with Anba and wait for follow-up. ### JS Input Masking 🎭 - Presenter: TOM - Slides: https://goo.gle/ecma-402-js-input-masking - Explainer: https://github.com/tomayac/js-input-masking/blob/main/README.md - JS polyfill: https://github.com/tomayac/js-input-masking-polyfill FYT: Thanks for the discussion. (1) Some parts of what you proposed… if the formats are the same across different regions, it shouldn't be part of Intl. For example, if the ISBN format is the same across regions, it shouldn't be in Intl. (2) Is the name "input masking" correct? (3) A new item to consider is the postcode. That differs a lot around the world. The US has 5-4, India has 6 digits, Canada has special alphabetic rules. (4) It would be good to validate whether a string is a valid input. For example, maybe 13 digits is a valid ISBN, but not 14 digits. (5) A Googler on our team built libphonenumber, and it ended up being their full-time job for a while. TOM: Postcodes are interesting. For validation, that's interesting and useful. Thanks for confirming that it is useful. I think it would make sense to have it in the proposal. EAO: (1) Having built a library like this in the past, you start facing the issue of how to report errors on the input. So it becomes error reporting, but you need to do a best effort at the formatting while also reporting errors in a side channel. (2) Formatting while the string is being edited is just really hard; you should just wait until the field loses focus. TOM: I agree that live updating the field is challenging. What you said about error reporting is interesting. Verification needs a lot of thought. I think it's something most developers probably want. EAO: The biggest question is, how does the side-channel error reporting happen? Because that's an interesting question for a UI component like this. TOM: It seems like it could hook into the mechanism for email verification that we already have. And for on-the-fly formatting, hopefully you could write the formatter so that it can listen to whatever event the developer thinks is the right event. EAO: It's not just about a binary error. It's about providing more context to the error messages. TOM: I think many things can be done. I'm new to this area, so I don't know the precedent. I'm looking for more experience. ZB: Thanks TOM for the presentation. I've worked in this area before. I'm excited about the space, and I have a lot of questions. (1) Parsing is hard. There are a lot of questions here. What happens if they write LTR and RTL? What happens if they type in Arabic numerals? What if they use different kinds of separators? You quickly get into an uncanny valley. (2) You should also think about address formatting, which is like postcode and phone number. Where do you stop? (3) International placeholders is an interesting topic. How do you present a placeholder for a phone number? That really depends on the region. (4) I'm not sure that adding ??? is good for the scope of the spec. (5) About whether this belongs in a spec. It seems like a lot of UX teams will want to customize exactly what the output looks like: they agree on most of the format, but want to change a couple things. There's a good question about how much of this is i18n. (6) And finally, and this is the strongest point, if we were to specify what you are specifying, we would need to back it with a strong library. Because speccing it in ECMA-402 doesn't give us everything. So why not start with writing the foundational library, maybe one that can be used in many different programming languages, and then once you have the library, come back to ECMA-402 and ask whether we should bake it into the browser? That can then help us answer questions about whether the payload is sufficiently high such that it makes sense to ship it in the browser. So basically, I think we should start with a library. I think ECMA-402 is likely not the right place to start. TOM: We could build a library, but we run the risk of making the "15th way of doing things" (in reference to the XKCD comic). Temporal started by making a polyfill, and is now integrating it into the browser. We already have a lot of input masking libraries. RCA: I think this is really useful. (1) I'm concerned that the scope could be very large. (2) I'm concerned about what ZB said; organizations where I've worked have wanted to have their own way of doing things with slightly different interactions and so on. That formatter could be a custom thing for that institution. (3) Another thing is the interoperability with HTML. You could have an input credit card, the pattern, the validation, etc. (4) Highly interactive input fields could slow performance on low-resource devices. TOM: For performance, the obvious tweak would be to do validation on the server. YSZ: I think this is a super important part of the application. (1) Like FYT said, some of this data is not Intl data. (2) Phone validation is very complicated, like ZB said. We need to care about the UI; for example, inputting the credit card should trigger a numeric keyboard rather than an alphabetic keyboard. So it seems like we need <input type="phonenumber"/>. Did you consider starting there? TOM: I thought about that, and I put it in the explainer as an alternative. SFC: In order to avoid the "15th standard" issue, you should approach the industry leader in i18n standards, the Unicode Consortium, about making a working group to establish the industry canonical solution. ECMA-402 looks for prior art, and Unicode is the place we point to most often. This is similar in a way to the MessageFormat Working Group, which was chartered to resolve the competing standards for MessageFormat by bringing all the authors together. TOM: Yeah, reaching out to Unicode and seeing if this has come up before would be a good option. As I've said, I had this in the String prototype, and then realized that this should maybe be Intl. Credit card numbers are generally not Intl, but phone numbers are. So creating that prior art makes sense. ZB: I had discussed this a few years ago with Unicode. But with what SFC said, where there are multiple competing libraries, it means that we don't know what the answer is yet. Once we put it in ECMA-402, we won't be able to change it. When writing a library, we can make it and discard it with something better later. It makes sense that we need a place to assemble expertise from the many organizations. Maybe Unicode is the place. And only after we have that canonical implementation, we can evaluate whether it fits in ECMA-402. MCM: The question about new input forms was raised earlier. Did you list use cases where form input types would NOT be sufficient for, where you need the JS APIs? TOM: In a Node.js server, and you have a CSV file of unformatted phone numbers, you might want to format on the server. So it makes sense to have isomorphic Node and client-side behavior. MCM: Has Node.js said that they need a standard for this? Aren't there already Node modules for this? TOM: Deno is an interesting case. They've started implementing Web APIs like fetch. Programmers are used to the way Web APIs work, and they use them in Deno the way they expect them to work. ### LookupMatcher should retain Unicode extension keywords in DefaultLocale #608 GPT: Seems reasonable to me. EAO: +1 CJR: +1 #### Conclusion OK to move forward with this change; review the final spec text when ready. ### ships the entire payload requirement #588 #### Conclusion FYT to follow up with Anba's suggestions on the Intl Enumeration API to harden the locale data consistency. ### DateTimeFormat fractionalSecondDigits: conflict between MDN and spec #590 GPT: It seems reasonable to match the Temporal behavior. SFC: Do we want to add 4-9 now, or wait until Temporal is more stable? #### Conclusion Seems reasonable to move forward with a spec change. Still some open questions from Anba and SFC. ### Presumptive incompatible change in future edition erroneuosly listed #583 RGN: The spec version is immutable. FYT: Is there a way to publish errata? RGN: I don't think so… I do see some errata on ECMA International, but I don't see references to those errata. SFC: The PR in question is #471. It was merged in January. I don't know why the change to Annex B made it into the edition, but not the normative change to numberformat.html. FYT: The other issue is that we have long tables in the PDF that get cut off. RGN: We're trying to raise funding to generate the PDF by a better mechanism. #### Conclusion Ujjwal to investigate. ### Accept plural forms of unit in Intl.NumberFormat #564 CJR: If we accept the plurals in RelativeTimeFormat, I can see a case for doing that also in NumberFormat. SFC: There are basically 3 approaches. (1), we only accept singular units. (2), we accept plural forms for all units… stripping off the "s"? (3), only special-case duration units like days and hours. EAO: Pluralization for all units is challenging. "inches", "kilometers-per-hour" CJR: Having listened to your explanation, SFC, I agree with your assessment. Doing it on an ad-hoc basis is leading away from consistency. RCA: +1 for not allowing plurals. RGN: I share this opinion. Is there already a reference to CLDR, to prevent this from coming up again? #### Conclusion Stay consistent with CLDR, and add a normative reference to CLDR if there isn't already one.
This comment was marked as spam.
This comment was marked as spam.
|
@ben-allen will write a PR to add text to the spec describing the requirement. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This request came from YSV in the 2021-05-25 TC39 meeting
"
YSV: .... we would require — and I read through the spec, I don't think that the spec is permissive, in the sense that this wouldn't be a requirement — the requirement for us in order to make sure that the fingerprinting part doesn't become an issue is that any implementer who implements this API also ships the entire payload. So those are the two high-level issues we've got.
FYT: Sorry, can you clarify, when you say the entire payload, what does that mean?
YSV: So you can't for example ship part of the data you're referencing. For example, for the calendars and languages, you have to ship all of it, you can't just ship a subset.
...
SFC: I wanted to reply and clarify on YSV's second ask about requiring that implementations ship all the data. If I understand that correctly, I interpret that to mean that in order to resolve the fingerprinting concern, the set returned by this function needs to be equal to the browser version number. And I think it's an interesting concern that warrants additional discussion. I'm not convinced that that this API is going to cause any fingerprinting concerns in its own right. Because if we do get to a point where browsers are, you know, downloading additional locales on the fly, which would be definitely a nice thing to shoot for, that's going to raise the same types of fingerprinting concerns that this proposal would expose. For example, if you were to call create a date-time format in — pick your favorite esoteric locale, how about Klingon — if you were to create a DateTimeFormat in Klingon, and that is producing strings for you, and then Klingon gets added to the available numbering systems, both of those are equivalent fingerprinting concerns. So I’m not convinced that the requirement that browsers ship all data is necessarily unique to this proposal and I don't necessarily see that fitting in here.
YSV: Yes, you're absolutely right. This isn't going to be unique to this proposal. This is the first proposal that we're asking for this, but this is, if this goes forward we will be asking this from all proposals, that there will be no partial data sets being shipped.
FYT: Can I ask something here with that? I'm not quite sure about that. Because as you can see here, in this particular API the possible keys we have are
"calendar","collation","currency","numberingSystem","timeZone", and"unit". So whether we ship 100 locales or 10 locales is not discoverable by this API, because"locale"is not one of the keys. Whether we ship with ten locales may impact it, but not 100 locales. First 10, locale. So, I'm not sure. I mean, I understand the fingerprint concern. If one of the possible keys is"locale", fine, the thing you require has merit. And if you're saying, please ship all the calendars, then I agree with you. But in this particular case with regard to not shipping all the locales, ten or 100 shouldn't be observable by this API at all. So I don't know that that will be impacting the fingerprinting concern.YSV: Sorry. Did I say locale? I mean specifically that we don't ship partial data sets of these things that we're going be exposing in a discoverable way. I don't know if I said locale there, but that was my meaning.
FYT: Thank you for the clarification. So I think what you're saying is that we should be shipping all calendars, all collations, all currencies, all number systems, all time zones, and all units. Is that what you mean?
YSV: Yes.
FYT: I understand what you're asking. I will bring that back to TG2 for that discussion. Thank you.
YSV: Yeah. And this also comes with — any future APIs that do something like this, are required to ship the full data set as part of their implementation.
FYT: Could you clear up? What do you mean by 'like this'?
YSV: Because there's a very vague if we have other enumeration APIs we don't ship partial data sets.
...
JHD: This is a reply to YSV's thing. So it seems totally reasonable to find a way to mandate the full data set, instead of partial ones, because that reduces the fingerprinting landscape, but I think that's completely orthogonal to this proposal because I can do all of the same fingerprinting that I could do with this, without this. It just means I have to do a little more work in advance, but it's not that hard. I just have to go to a bunch of browsers and build a long array of possibilities and then try them. So I think that it's fine if this proposal surfaced the need for that requirement, but I would hope that that would be pursued independently and not be chained to this proposal.
...
USA: I wanted to echo what JHD was saying in that my understanding of this proposal is that doesn't actually incur any additional data and it just provides a convenient API to have the data exposed in a certain way, but if anybody wanted, they could have access to this data anyway. We have userland modules which do some of these interesting operations and get this data. So just for convenience reasons.
"
The text was updated successfully, but these errors were encountered: