Upcoming WHATNOT meeting on 2024-07-25 #10496
Comments
|
@past I18N would like to participate in the next call. Our list of issues is here. It's a long list and we do not expect to "take over" your meeting to resolve these. Chief on our list of issues are:
|
|
Sounds good, I tagged the 2 topics for next week. |
|
Curious if there can be a discussion of the status of #5841 at some point. |
|
@past I can't find joining info? It's now (4 PM America/Los_Angeles on 2024-07-25) right? |
|
Thank you all for attending the meeting last week and special thanks to Domenic, Chris H and Joey for swapping off note-taking! Here are the notes from this meeting (the next one is at #10534): Review past action items
Carryovers from last time
New topicsI18n issues: [addison]
Action Items
MinutesInvoker buttons double-dash prefix Mason: Earlier today OpenUI agreed on kebab-case instead of camel case. The WHATNOT resolution was custom commands would use a single dash prefix. OpenUI folks that that was strange and different from the rest of the platform (custom elements, data-*, CSS double-dash prefix). So the preference was double-dash, if it's amenable to WHATWG. Olli: single-dash is used by vendor prefixes. Mason: That was brought up. Vendor prefixes are -(vendor name)- but a "no-vendor" vendor prefix would be --. (According to Brian Kardell.) Mason: it sounded like the WHATNOT discussion was OK either either single or double dash. Still OK? Olli: (grunts OK) Everyone else: (silence) domenic: have you talked about doing data-? mason: it is the attribute name, not the attribute value. we discussed a lot of options and it boiled down to 3: single dash, double dash, and non-alphanumeric. data- wasn’t listed, we were looking at shorter things. domenic: lets take a tentative conclusion on double dash. mason: i would assume that people would not like data dash. domenic: i dont want to block, until further notice lets do double dash Review past items: looking into redact ancestorOrigins Chris H: I talked to Kastuba and Mike West. They agreed they owned this space and will talk to the teams about making the change. They agree that it's a bit odd that referrer policy doesn't censor origins. So, we're waiting to hear back. Internationalization topics: internationalized email addresses Addison: view from 50,000 feet: a long time ago we had #4562. Long-ago we had a PR #5799. Today I recreated a new one #10522. Not a lot has changed but I tried to answer some of the review questions. We discussed in this group in February. Would like to move forward and fix verbiage things, unless there are objections. Domenic: Anne has been most involved; also Henri Sivonen. I’ll try to channel then. It’s not just a matter of changing validation because one you allow these chars to be input how do they get sent to the server? There’s a long thread with IETF people on this, and there wasn’t really a conclusion about what to submit to the server. Addison: I think we’d arrived at send the unicode string to the server. If they need to use it in a mail context or the like they’ll need to do transformations and so on. It’s a specialized string input, we don’t need to invoke all the to-ascii stuff. John Clemson is pretty vocal; that point isn’t new. If the right people aren’t here today, let’s cover this in a future meeting when Anne/Henri are available. Henri had a bunch of questions, I’ll take an action to answer them. Mason: Chromium supportive of the goal, defering to the experts on the how. Chris H: Are there particular sites that have expressed interest in using this feature? Addison: We get push from some group whose name I forget, people at IETF who are promoting accessibility of internationalized domains. Regularly. In terms of real-world stuff, we know that many people in China have left and right-side email addresses like this, also the Middle East. Acceptance of such emails is spotty beyond just the web. Gmail does support such emails. Chris H: Maybe we can ask the Gmail team for their take on the support, prevalence, demand. Mason: even if the fraction of users is small, it's important Chris H: implementation work sounds easy? Addison: basically changing the ABNF / regex for validation. Domenic: that's assuming we go with Addison's preference and not Henri's, if I understand correctly. Addison: the specs are complicated for the left side. Probably should just let the browsers pass through possibly-invalid strings on the left side and the server will throw if it's no good. Internationalization topics: interaction between Infra and I18n Glossary Addison: two problems. We're endeavoring to not build conflicting definitions. Glossary can point to Infra as authoritative. So I have a list of issues to file with potential changes to Infra. The flip side is that we want to make sure both of our documents can be used consistently by third party specification writers. Should we pull everything into Infra? Marcos: I raised an issue on the glossary that we can't use it in normative sections since it's a non-normative document. Addison: But to make the glossary a REC would be incredibly painful because it's a living document. Marcos: We could split it into two documents. Take stuff from Infra. Domenic: sympathy with W3C process being difficult. Splitting into two sounds like a nightmare. For non-W3C process; we want infra to have solid technical definitions, but we don’t want to move this away from the experts in i18n. Am I right the problem is mostly around spec tooling? Are there conflicts of dfn terms? Addison: one problem is I tell people to link to i18n glossary as if it's normative. And so this causes W3C process issues. Chris W: The W3C hasn't really looked at having definitive glossaries. It seems like an important use case that should be easier, even easier than what we have for living standards. I should raise with the W3C process CG and AB. E.g. it probably shouldn't have the same horizontal review requirements. I'll take that as an issue. Domenic: OK but what about the conflict with Infra Addison: one of the challenges is the , either in Infra or 18n glossary, which can break other peoples' specs. Want WHATWG to be aware of the potential and to have a good process for resolving the conflicts. Domenic: we could say that spec developers have to pick between the two. or, for those terms where there is overlap, we could make a namespace on the i18n glossary one. They could add an attribute for i18n on their link. For cases where there is overlap, infra should be linking to the i18n glossary. marcos: infra definitions - if i18n is going to be the one then we should make the infra ones go away addison: infra one assumes that strings are utf16 code units, and things are defined consistent with that, but its a willful violation of unicode terminology, but its useful. scalar value string for when you want code point string. i think thats a useful thing, our glossary is closer to ?? you want real terminology. thats the one place where i say i know what youre doing and dont want to interrupt it, but theres a difference there and we need to explain it carefully. domenic: does the solution i said work with that? “this definition is specialized for web stuff, but go see i18n for unicode cases” addison: yeah we could add notes to infra to say this is what we did here domenic: i think we will be amenable to that. addison: i want you guys to be aware that this is a thing, so we will try to swim in the same direction domenic: yeah we could add a checklist to infra pr saying is this a conflict with i18n glossary. ill take that action item More internationalization topics addison: we get copies of your issues that get tagged with i18n labels, and we occasionally file issues, and so im tracking a bunch and you can see the label i pasted in the chat. we’re happy for you to pull on us to make opinions. looking over this list, we will probably come back and discuss about date time input and bidi, and we would be happy to work with you in the call like this or separately to resolve a bunch of these. don’t be shy about pulling on our working group and me to make sure we’re helping out Animation frame callbacks in iframes Olli: please take a look! #10521 Chris H: The Chrome team is already working on it Chris W: probably we'll talk about it next time with Emilio |
What is the issue with the HTML Standard?
Today we held our weekly triage call (#10471) and I will post the meeting notes there in a bit. The next one is scheduled for July 25, 4pm PDT. Note that this is 1 week later in an Americas+APAC friendly time.
People interested in attending the next call please respond here or reach out privately to @past, @cwilso or the spec editors. We will be tagging issues for the next call again using the agenda+ label in all WHATWG repos and we would like to invite anyone that can contribute to said issues to join us.
The text was updated successfully, but these errors were encountered: