Meeting minutes
addison: is tehre something not on the agenda that people would like to discuss?
jyasskin: I'm especially curious about the <time> question
… which is on your list
Info Share
jyasskin: I might be able to help with you find people in Google to participate
addison: I can name names in the Google space of people who've shown interest in the past
… I'm happy to connect offline
<jyasskin> I co-tech-lead web standards at Google, so recruiting there is kinda my responsibility. I'm not super optimistic, but I'll look.
addison: people saving their horizontals for the end
<jyasskin> 1 other topic that I forgot is that Bliss Symbolics in the APA is looking for a way to include themselves in HTML, and Elika and I think they should use Ruby.
addison: not doing horizontal engagement early
… when it would do the most good
… tehre's not a lot of appetite to add more gates to teh process
… I also wen to the sustainability breakout
… it is a new horizontal
… which is about limiting things like impact of web tech wrt things like power useage etc.
… third, I met WebAuthn people
… i18n people may dimly recall that they had invented a serialization for addig language and dir metadata to fields
… at our behest, we asked them to put lang metadata and they did by suing the Unicode lang tagging chars
… no one has implemented this
… if they did, no one would understand what this encoiding is
… this morning I added a comment about what we discusseed doing
… which is OK, don't implement a thing that attaches garbage to the end of oyour strings
… adn potentially a dcouemnt level metadata instead
jyasskin: I was in the APA-whatwg session
… they were talking about Bliss symbolics
… the sugestion is to attach it when they like to use ruby to attach them
… when I talked to fantasai about it, she said that ruby actually has some of the same semantic variation that Bliss has
… they will almost certainly need a language tag for bliss
… that doesn't seemm unreasonable
… you don't like the idea
r12a: we've been around this for a couple of times before witht he same people
… we definitely don't think it's a good idea to repurpose ruby as a glossing mechanism
jyasskin: it is a glossing mechanism
r12a: ruby was designed with a specific sort of target in mind
… and it has been develpoed with a specific target in mind which is CJKM
… I don't think it's a good idea
jyasskin: I feel strongly that HTML elements should have semantics and not just behaviour
r12a: a good example is that if you have japanese and you want to have normal ruby and you want to have Blissymbols
jyasskin: if you have effectively 2 different explanations fo the same text
… you have to mark them with the differences between them
… so we need a language tag for Blissymbols
r12a: in Japanese and Chinese in particular, depend on what kind of relationship the annotation has with the base text
… you're developing a tech that's not going to be widely standardized and used
jyasskin: you can say the same thign about ARIA
r12a: you could, but there's no reason to do more
jyasskin: fantasai was going to flesh out the semantic of the various ways Ruby is used
addison: OK, I don't want to be the last to know about it, though
<addison> Tristan
<addison> xfq: met with a11y guidelines
<addison> ... will do early review of WCAG 3
<addison> ... they will send it to us and incorp our checklist into their wcag3 process
<addison> ... will try this process and see if it is working
r12a: we spent a lot of time about the short review checklist
… I don't think we want another gating point
… we want peoople to apply the principles of i18n as they're doing the work right from the beginning
… that's what I was saying to the a11y people
… not look at the short review checklist after they develop something, but they should look at it before they develop something
… and they should follow the links in the right hand column and read that
… FPWD is too late
… it's a sort of gating point
… I don't know if we need to create a video that says here's the short review hcecklist
… and here's the longer checklist and how to get there
… and you should read all these things and go through these points one by one
… and they can play that video before FPWD
addison: @@1
Glossary Publication at Note
addison: I had a hallway conversation with plh
https://
addison: as you know we have the i18n glossary
… which is a Note track document
… which contains all the i18n terminology that is not found in INfra
… we tell people to use these terms in their specs
… one of the challenges is that they get a warning from spec that says you have used a non-normative ref in your normative section
… wheyn they link to a term like code point to our glossary
… and we're a special case
… it was suggested in a coulple of places that we might become a living stdardn that would avoid that problem
… but doesn't seem to make sense
… that's too heavyweight
… becae we update the glossary all the time
… and it's not a registry
… the main thing we need to do is publish it with the Note status and not Draft Note status, which is what is currently is
… and then continue to publish it as a Note
… and then adjust the tools like respec to make it special
jyasskin: do you feel like the terms of the glossary affect the behavior of any normative specs that refer to it or are they just for understanding?
addison: they are for understanding
… it's helpful to not have people to have to copy the defs out
jyasskin: if everything in the glossary wouldn't change the test cases it seems fine for it to be a note
addison: like code point, we don't mean UTF-16 code point
addison: any other comments on glossary?
Advancing LTLI
addison: we have a document called Language Tags and Locale Identifiers, LTLI
… I have an issue that I own in specdev to harmonize the reqs between these 2 documents
… mostly mean importing the guidance from LTLI to specdev
… I think that's worthwhile
… I have a draft
… some time real soon now I'd like to advance LTLI
… I don't think there's other work on that
… I think it's mostly up to date
… I'd like to do a wide review again
… and publish that out
… so I want the WG aware
PR and Issue Review
addison: any comments?
<gb> Pull Request 136 Change the guidelines about establishing base direction and mention ALM (by aphillips)
addison: this one is about guidelines about establishing base direction and mention ALM
<jyasskin> Speaking of not being last to know, there was progress on whatwg/
<gb> Issue 7039 Proposal for Element.currentLang and Element.currentDir (by claviska) [addition/proposal] [needs implementer interest] [i18n-tracker]
addison: fixes 2 of the oldest issues against specdev
<gb> Pull Request 133 Add a new guideline about ruby markup (by xfq)
r12a: I had a quick look at specdev #136, you might need to explain or point to an explanation of what ALM does
<gb> Issue 136 not found
r12a: which most people have no clue
addison: it's only 11 years old
r12a: it's a bit of a weird one
<r12a> https://
addison: I resisted the temtation to add the descriptoin
… but I can add that
r12a: ALM determines the order of digits in a sequence
… it's used for Arabic, @@, and Syriac
… but it's not used for Persian
… I mean the Arabic language, not the Arabic script
[addison does a demo]
<r12a> https://
addison: the second PR is the new guidelines about ruby markup
… it is about our earlier conversation about ruby
jyasskin: I feel like it's a mistake, but I don't have the context to actually say that authoritatively
addison: we can hold off on it since we actually had a conversation today
<gb> Pull Request 77 Update orthographic syllable related definitions (by r12a)
r12a: we can publish it and if it turns out to be incorrect advice then we can change it
addison: this one is against the glossary
xfq: this is to address the comments from Norbert Lindenberg
ACTION: richard: tidy specdev PR#77
<gb> Created action #133
<gb> Issue 21 Value of default direction (by r12a) [help wanted] [devt] [Agenda+]
<r12a> #133 note w3c/
<gb> Added comment
addison: Value of default direction
addison: it was proposed to make auto the default direction in place of ltr
https://
jyasskin: does this have any implication on implementations?
addison: it should have no implications for impls
… this is guidance to spec writers
jyasskin: OK
addison: some standards have a longstanding default base direction of ltr
… auto seems reasonable
… since in most cases if you have strong rtl chars it's at the beginning
<jyasskin> +1
addison: auto's default is ltr
… in the absence of any strong rtl chars
addison: is there any objection to my making the change?
xfq: sounds good to me
Preparing for WHATWG
addison: a bunch of of bidi issues
<gb> Issue 1819 Should dir=auto with no strong characters inherit directionality from parent or be ltr? (by w3cbot) [close?] [tracker] [s:html] [i:bidi_text] [spec-type-issue] [alreq] [hlreq] [t:bidi_markup] [Agenda+I18N+WHATWG] [whatwg]
addison: I have a call out on an issue that is related to bidi which is ^
addison: fantasai has expressed the opinion that dir=auto @@
r12a: @@ ALM
[addison demonstrates the issue]
jyasskin: this is a probably too aggressive suggstion, bu t I wonder if the auto algorithm isn't paying enough attention to whether the content is weakly directional
addison: no, it's looking for a strongly directional char
… if it doesn't see one, is uses its default
jyasskin: thinking about how to get the impls to change, whatever we write in the spec, the impls will be highly constrained by compat
… unless there's a strong argument
… if the person that broke was clearly doing the wrong thing, that has a chance of convincing the employers
… but if they weren't clearly doing the wrong thing, then probably everyone's gonna prioritize compat
addison: you can see that it's complicated
jyasskin: yes
jyasskin: just reading the bug it looks like all 3 impls are inclined to not change anything, to keep auto to ltr
addison: it is very frequently ltr speakers are making decisions for rtl language users
… and it is hard to work with rtl everywhere
… as a group we tend to bias towards rtl users
… if you don't have any rtl, none of this bothers you, but if you have rtl text, this bothers you all the time
… and if you talk to individual non-technical users there, @@
jyasskin: I think your bias is correct
… you should prioritize the needs of the rtl speakers
[r12a shows a demo]
addison: different Arabic script languages do have different preferences wrt neutral separated number sequences
r12a: Arabic and Persian would expect it behaviour differently
jyasskin: that makes it really hard to justify a change in the default
addison: that's only one corner case, though
… there are a lot of neutrals that are not number neutrals in weak directionals that are not numbers
… because you want the isolation
… and don't want spillover effects
… between the value that's being inserted inside the span and the value on the outside
jyasskin: this is again for convincing the implementers, not just arguing
r12a: yeah
[addison shows a demo]
jyasskin: I like your currency example because it shows broken behaviour with the current thing in a realistic situation
… I would suggest posting this example at least
… I don't want to wait on what this group prefers
addison: this example includes strong chars inside of the isolate, and this issue is about only neutrals and weaks
jyasskin: it would be good to have a realistic example where you have a reason to isolate
Break (until 11:00 Pacific)
WHATWG prep (continued)
r12a: I was hoping the blackletter discussion would create further discussions about how the browser knows what to do when somebody says they want more
https://
addison: I updated the agenda for the whatwg meeting with some links
… if you get a chance you might want to click on the summary links
… do we want to spend more time on base direction of neutral isolates?
… I got an email from Shane Carr who wants to dial into our meeting with whatwg
… I had an action to talk to him
… he's the author of semantic skeletons
… draft at Ecma
… adding time formatting attributes to input type=@@
… in our Monday meeting we also talked about the fact that HTML has language about respecting the locale of an input type=@@
… but it's inconsistently implemented
https://
https://
https://
addison: as I mentioned before, there's a couple of broad categories
… if you go to t:loc_time
… then there are things related to time
addison: inncluding some that are not agenda+
… any thoughts?
<r12a> is:issue is:open label:t:bidi_markup,bidi_text label:whatwg
<gb> Issue 7039 Proposal for Element.currentLang and Element.currentDir (by claviska) [addition/proposal] [needs implementer interest] [i18n-tracker]
<gb> Issue 326 TPAC 2024 meeting (by past)
addison: create a TF to do a regular call to work through these?
… with WHATWG, like our CSS call
… our total whatwg list is 86 open issues
r12a: we have 17 needs-resolution issues
r12a: +1 to creating a TF
Bert: it's an effecient way of working but it depends on whether there are people available to come to that meeting
xfq: I'm not opposed to the idea, but depends on whether we have time, the frequence, the time slot etc.
addison: let's propose it first
xfq: have a look at ^
addison: Lea added a comment 20h ago
addison: unhappy to see this first time this morning
… the proposal is better than the current situation
r12a: I guess the question is how they're struggling with
… if you're a content author and you knew that you'd labeled certain things with a particular language tag
… then you remember what that language this was
addison: I think fantasai mentions that intermso f providing some kind of method for computeLangMatches
… so that you can do some queries like that
r12a: if ou want to dothis as returnign an boject rahter than as a string
addison: I would return the string
… if you force it to go through an ojbect like Intl.Locale
… you might get garbage
r12a: if you use :lang(fr) lang is fr-CA, taht still matches, right?
addison: yes
… but the el.computedLang is fr-CA
addison: does el.computedLang === 'fr'
r12a: we need to advise authors on how to use that in that string
… you need to get the string so that you can do something
addison: it occurs to me that computedDir might have a subtlety in it
… if the element directoin is auto
… would that return ltr from the actually computed value as opposed to just saying auto
r12a: I was just wondering the same thing
addison: I think that's a comment worth adding
r12a: why do they want to know what the direction is?
… for diagnostics could be useful sometimes
addison: if you grab an element and you change the content of this element then the value of computedLang might change
r12a: probably just want to know *at the point* when you ask what the direction/language is
addison: might be super interesting for an input box what the behaviour might change
… after some inputs been put in the field
r12a: in input fields where you don't have an explicit declaration of the direction
`dirname=foo` so `foo=ltr` on submit
<r12a> https://
<gb> Issue 2404 A tag to display date and/or time to the user in his preferred format. (by lostmsu) [addition/proposal] [needs implementer interest] [i18n-tracker]
addison: anything else we want to talk to them about?
https://
r12a: for Syriac Noto try to harmonize all the styles
… including Latin
… they tend to be sort of simple and blocky
… the user should be able to choose whether they want all guards off
… or all guards on
… or something in between
… it could work a bit like cookies
xfq: let the user add an allowlist or something
The possibility of a configurable, per-user opt-in to exposing some or all User-Installed Fonts, or a per-origin opt-in, is being discussed.
r12a: in chris's document ^
r12a: Safari has implemented this
… you can only systems font
… so I never use Safari these days for multilingual stuff
… that's really bad
… although I think you could do webfonts
r12a: you could be working on an intranet
… you should be immune from this privacy issue in those situations
… so the browser shoudln't hinder from using whatever you want
… or localhost