Meeting minutes
Agenda Review
Action Items
<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> #145
<gb> Action 145 publish timezone for wide review (on aphillips) due 2024-11-28
<addison> #143
<gb> Action 143 make comments on the encoding issue attached to i18n-activity#1940 (on aphillips) due 2024-11-28
<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> #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
RADAR Review
<addison> https://
addison: two new incoming ones
… WebCodecs
… due Feb 28
… I took a brief look at it
… I'll take it
… the next one, WebRTC
… we last reviewed WebRTC in 2016
… it's a REC
… they're publishing some amendments to it
xfq: I'll take this one
Pending Issue Review
<addison> i18n-activity#1945
<gb> Issue 1945 Canvas TextMetrics additions for editing and text styling (by w3cbot) [pending] [tracker] [s:html] [whatwg]
<addison> i18n-activity#1957
<gb> Issue 1957 Ambiguous parameter comparison definitions (by w3cbot) [pending] [close?] [tracker] [s:controller-document]
Publish string-search as FPWD
<addison> Some time ago we split off materials in string-search from Charmod-norm. These materials have received some work, even though we are not actively developing this document. Most recently we merged an example from hsivonen.
<addison> We have not published this work to TR, however. The question is whether we should publish a DNOTE as FPWD.
addison: I merged the changes to string-search
… I noticed that we've never published it to /TR
… would we like to maybe publish string-search to /TR as a DNOTE?
<addison> https://
r12a: does it have appropriate words at the beginning to say this is still very, very drafty?
addison: I think it does
r12a: I would recommend that we have some kind of banner that says this is very much just the stuff that we've thought of so far
… and we will continue developing this over time
addison: OK
<xfq> +1 with the banner
<addison> proposed: publish string-search as FPWD with an appropriate banner
<r12a> +1 with the banner
<addison> +1
<JcK> +1
RESOLUTION: publish string-search as FPWD with an appropriate warning about the maturity of the materials in a banner
ACTION: add a banner to string-search
<gb> Cannot create action. Validation failed. Maybe add a banner is not a valid user for w3c/i18n-actions?
ACTION: addison: add a banner to string-search
<gb> Created action #149
addison: this has been a very useful thing in the past because people periodically discover that they want to create a string searching spec
ACTION: xfq: add string-search to i18n-editors and get an echidna token
<gb> Created action #150
String-Search PR for IVS
<addison> w3c/
<gb> Pull Request 24 IVS in string searching (by xfq)
<gb> Issue 21 IVS in string searching (by xfq)
<addison> xfq: I filed an issue about this last year
<addison> ... some people searchnig have a base character with a variation selector
<addison> ... awhile ago I raised a PR to add text to string searching
https://
addison: this isn't really an orthographic or dialectical variation
… it's yet another kind of encoding variation
… I would pull it up a level and maybe put it after the East Asian width subsection as its own subsection
… because those are both kind of encoding variations you find in CJK
… otherwise, I thought the text was pretty good
… images would be helpful
… there are two problems
… one is if you type in text with your IME
… and you don't have the variation selector, then you don't find text that has the variation selector if you're just doing naive code point matching
… and the other is if your IME produces the VS you won't find unmarked text or text with a different VS
… even though they're all really the same on some level
… so I think you do an okay job of spelling that out
… I'm maybe a little bit dubious about the possibility of people adding a feature of search or find commands for fuzzy vs non-fuzzy
JcK: I think I agree
r12a: it's not only Chinese that uses variation selectors
… I think we should give some though generalizing this a little bit, perhaps using Chinese as a good example
… but Mongolian uses lots of variation selectors and other scripts too
… so I think the concept here is that if you have a VS then you need to decide what to do about it
addison: for IVS Unicode has a registry of them
… so that may be a subsection of that
r12a: it's slightly different
… but it's all part of the same thing
… the main thing is that chars can be followed by this thing called a VS of one type or another
r12a: maybe renaming the section to something like "sequences with variation selectors"
I18N+CSS prep
addison: we have an i18n+css call coming up on Tuesday
… does anybody have anything particular that they want to discuss about?
<gb> Issue 1944 [css-text-decor] Control the line height of text containing emphasis marks (by w3cbot) [tracker] [s:css-text-decor] [spec-type-issue] [jlreq] [clreq] [mlreq] [klreq] [t:typ_misc] [wg:css] [i:emphasis]
[xfq describes the issue]
addison: you want the line spacing to stay the same and you want the marks to appear
… anything else on that call?
Vertical lists article
<r12a> https://
r12a: I rewrote some bits
… if you read this early on, you might want to read it again
… we can't test @@ because none of the browsers support the digits value
… the other thing is that when Japanese people were looking at these examples they all started saying text-upright digits numbers
… I was wondering maybe I should add another section that says "what about positioning?"
https://
xfq: we have 7 open issues against this article
… ideally, we should close them before publishing