Meeting minutes
Agenda Review
Action Items
<addison> https://
<addison> #153
<gb> Action 153 ask PLH what happened with wasm-2 CR since we have an issue open (on aphillips) due 2024-12-26
<addison> close #153
<gb> Closed issue #153
<addison> #152
<gb> Action 152 request FPWD of string-search (on xfq) due 2024-12-26
<addison> close #152
<gb> Closed issue #152
<addison> #150
<gb> Action 150 add string-search to i18n-editors and get an echidna token (on xfq) due 2024-12-19
xfq: Not done yet.
<addison> #148
<gb> Action 148 propose specdev text related to design-principles#464 discussion (on aphillips) due 2024-12-12
<addison> #147
<gb> Action 147 Follow up on normativity warnings about glossary (on aphillips)
<addison> #143
<gb> Action 143 make comments on the encoding issue attached to i18n-activity#1940 (on aphillips) due 2024-11-28
addison: Need to look at 143......
<addison> #142
<gb> Action 142 check if we can publish the new version of jlreq (on himorin) due 2024-11-21
<addison> #135
<gb> Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17
<addison> #127
<gb> Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30
<addison> #89
<gb> Action 89 update i18n specs to support dark mode (on xfq) due 2024-04-18
<addison> #33
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
addison: I closed some
<addison> #7
<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023
<addison> #4
<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023
Info Share
xfq: There is a formal objection on CSS, but it's on the agenda already.
<xfq> https://
<addison> https://
xfq: clreq, with restructure of language matrix. Published to TR ^^
RADAR Review
<addison> https://
addison: No incoming requests
Bert: Media Capabilities not yet
Pending Issue Review
<addison> https://
<addison> #1971
<gb> Issue 1971 not found
<addison> i18n-activity#1971
<gb> Issue 1971 Clarification on `unicode-bidi` for `input type text` and `ruby` (by w3cbot) [pending] [tracker] [s:html] [Agenda+]
addison: What seems interesting is issue 1971.
<addison> whatwg/html#10896
<gb> Issue 10896 Clarification on `unicode-bidi` for `input type text` and `ruby` (by Ahmad-S792) [topic: rendering] [topic: forms] [i18n-tracker]
addison: I'm starting to think about it.
… Please, have a look.
How to make list markers stand upright in vertical text
<r12a> https://
r12a: Japanese discussion about space around counters. I added a section about that.
… There' sbeen quite a bit more change to the article.
addison: Home work for next week?
ACTION: addison: remind folks to review the qa-upright-counters-in-vertical doc for next time
<gb> Created action #154
Normativity of i18n-glossary
addison: We talked last time with Philippe about the glossary, about making it a Rec, a Registry...
xfq: It feels weird to make it Rec track or a Registry. But there are a few (not many) definitions that look normative.
… So we may make it normative in the end.
addison: We will have to make separation between the normative and non-normative definitions.
r12a: First step is to find out which defs are normative. Who has the action to do that?
addison: No one now.
xfq: If we use Unicode def...
ACTION: addison: review glossary definitions for normativity or candidates for normativity
<gb> Created action #155
addison: It won't separate neatly, some defs are imported, some are informative...
… I can start make a table.
xfq: Sometimes a part of a def is normative and some parts are illustrative.
Bert: I do think visually separating the normative and non-normative parts is the best way
… although it will have to be a lot of work
addison: I think that's valid
atsushi: Wondered if we can simplify things.
… Terminology.
r12a: Let's look at what we're dealing with. Probably not many at all.
… The ones that point to Unicode are not normative in our glossary. And shouldn't be exported.
addison: Most of it not written in normative style.
CSS Font Fingerprinting
<addison> https://
https://
xfq: At TPAC, I had a meeting with folks from CSS, PING and TAG.
… We discussed the issue.
… We had a rough consensus. We should give the user options to configure local fonts.
… Brave browser is in Privacy group, but couldn't attend the meetings.
… CSS received a Formal Objection from Brave.
… They don't want the compromise.
<addison> Chris Lilley wrote this for TPAC: https://
xfq: The spec allows an implementation to either allow or disallow local fonts to balance privacy and i18n.
… Brave was not satisfied.
r12a: I think I saw that Peter Snyder (Brave) agrees that uses can have control.
<r12a> see:
<r12a> ----
<r12a> If the Web is going to flourish and win over other application platforms,
<r12a> it's not sufficient to pose such concerns in an either/or choice and stop
<r12a> there (or to ignore Web users who need the platform to both protect their
<r12a> privacy AND include top-tier internationalization support). Yet,
<r12a> unfortunately, this is exactly what the WG has done over the 4+ years we've
<r12a> urged them to address this issue. It's possible the correct solution hasn't
<r12a> been proposed yet, but that's a reason to keep working on the problem, not
<r12a> leave it be.
<r12a> ---
addison: s/ that users/ that users
<Bert> s|addison: s/ that uses/ that users|
<addison> Chris's doc quotes CSS4 as saying:
<addison> ---
<addison> The default set of installed fonts will vary by UA, platform, and locale; it is important that users be able to customise which installed fonts are available for rendering web pages and to which generic font families, if any, these fonts are mapped.
<addison> ---
r12a: The quote above seems to say that users need to control this.
xfq: CSS needs to work on it. Anything we can do?
<addison> https://
addison: My quote is from this spec ^^
<addison> > UAs may choose a hybrid approach, where some user-installed fonts are initially exposed for internationalization, but others aren’t. Again, users should be able to customise this starting set.
addison: It also says ^^ (‘hybrid approach’).
<r12a> UAs are expected to also provide a convenient means for users to add and subtract fonts to meet their particular needs.
addison: the ‘should’ is not capitalized, not clear if it is a normative word.
addison: Does CSS want us to say anything?
r12a: It's between CSS and Brave. But the CSS spec doesn't seem as black & white as the FO says.
addison: We have a call with CSS soon.
Specdev changes related to TAG design-principles
<addison> We've been working with TAG to align the guidance in our document vs. design-principles. Addison had an action to propose text. Let's review the PR.
<addison> w3c/
<gb> Pull Request 149 Address differences between DESIGN-PRINCIPLES and SPECDEV (by aphillips) [Agenda+] [Best Practice] [normative]
addison: We noticed our doc didn't agree with the TAG's design principles.
<addison> https://
addison: I attempted to make changes to specdev, see the pull request and preview ^^
… Ours *looked* different but isn't essentially different. This change spells out when to use USVString and DOMString.
xfq: It kind of phrased the guidance the other way round.
addison: I want to try and get the TAG to use our text.
addison: We want most interface definitions to use DOMString, and we don't want them to mix DOMString and USVStriing.
addison: If the TAG's design principles are wrong, we don't have to be consistent with them.
… Similar to discussion about NFC. Normalizing is probably a good idea, but nobody is requiring it.
… I should probably add something about interface definitions.
Bert: not specific to this spec but I was wondering in general how specific to JS this discussion was
… DOMString seems to be a rather strange thing that I don't encounter anywhere else
addison: TAG and WHATWG would like to claim this is for the web platform as a whole
… in practice, that means JS and DOM strings
Bert: I'm not sure about JSON
addison: MessageFormat 2 required checking surrogate pairs but we removed that, at least for the text parts.
Bert: MessageFormat 2 it's not more like DOMString but more like USVString?
AOB?
addison: We have a CSS joint meeting on Tuesday.
xfq: Regrets for next three meetings.
addison: Will you have to time to the reviews before then?
xfq: Better let somebody else do them.
atsushi: It's only proposed amendments, isn't it?
… I can do WebRTC in next two weeks.
addison: I'll take the VC specs