Meeting minutes
Agenda Review
Action Items
<gb> Found actions in w3c/i18n-actions: #51, #50, #49, #48, #47, #46, #44, #43, #42, #41, #39, #35, #33, #32, #18, #16, #12, #11, #10, #8, #7, #5, #4
<addison> #51
<gb> Action 51 inform fuqiao and richard what to name the string-meta-2 repo (on aphillips) due 2023-10-12
<addison> #50
<gb> Action 50 raise TAG request about reviewing string definitions (on aphillips) due 2023-10-12
<addison> close #50
<gb> Closed action #50
<addison> #49
<gb> Action 49 contact unicode about emphasis mark skipping (on aphillips) due 2023-10-05
<addison> close #49
<gb> Closed action #49
<addison> #48
<gb> Action 48 work with clreq to investigate or produce a generics proposal (on xfq) due 2023-10-05
<addison> #47
<gb> Action 47 make the CSSWG aware of Warichu (on frivoal) due 2023-10-04
<addison> #46
<gb> Action 46 read the string-meta explainer and consider the new approach addison proposes (on xfq, r12a) due 2023-09-28
<addison> close #46
<gb> Closed action #46
<addison> #44
<gb> Action 44 follow up on the bidi thread of rdf-star (on r12a) due 2023-09-19
<addison> #43
<gb> Action 43 pull together the list of win/mac/etc apis for setting base direction and/or language (on aphillips) due 2023-09-18
<addison> #42
<gb> Action 42 work on tc39 proposal (meet with addison and eemeli to start) (on xfq) due 2023-09-18
<addison> close #42
<gb> Closed action #42
<addison> #41
<gb> Action 41 propose new specdev text on strings for xml (on aphillips) due 2023-09-07
addison: hoping to work on #43 next week
<addison> #39
<gb> Action 39 develop best practice guidelines for name-like fields (on aphillips) due 2023-08-31
<addison> #35
<gb> Action 35 make the edits of CSS #5478 (on fantasai) due 2023-08-30
<addison> #33
addison: xfq, please send an email to eemeli to say that we no longer need to do this any more re #42
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
xfq: will do
<addison> #32
<gb> Action 32 Approve the character markup PR (on fantasai) due 2023-08-17
<addison> close #32
<gb> Closed action #32
addison: we did #32
r12a: we pushed some CSS to tr-design
… did that CSS include the image styling?
addison: yes
<gb> Found actions in w3c/i18n-actions: #51, #48, #47, #44, #43, #41, #39, #35, #33, #18, #16, #12, #11, #10, #8, #7, #5, #4
addison: we should be cool in that regard now
<addison> #18
<gb> Action 18 Have informal explanation sessions about counter style translations with csswg members (on frivoal, fantasai)
<addison> #16
<gb> Action 16 Keep track of line-breaking in Korean for i18n-discuss#11 (on aphillips)
<addison> #12
<gb> Action 12 Upgrade/edit the explainer to address issues raised by google (on aphillips)
<addison> #11
<gb> Action 11 Triage all css properties to determine which are logical, physical, or na by default (on frivoal)
<addison> #10
<gb> Action 10 With florian triage richard's article into a list of potential generics (on frivoal, fantasai)
<addison> #8
<gb> Action 8 Create pr against canvas formatted text (on aphillips)
<addison> #7
<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github)
<addison> #5
<gb> Action 5 Check into how to list questions at the top of a digest and/or improve lang enablement communications (on r12a)
<addison> #4
<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on r12a)
Info Share
addison: about #4, I've recently unblocked part of it
RADAR Review
<addison> https://
addison: we have no new incoming requests
Bert: started vc-jose-cose
… lots of technologies that are not W3C technologies that I have to look up
… not finished
String-meta next steps
addison: last week, we discussed taking the stuff I added to the explainer and turning those into a note
… upon reflection, my proposal is to keep string-meta as the best practices doc and to create a requirement doc
r12a: I guess I had misunderstood what we were planning to do last week
… I thought this was all about doing something with the explainer
… making the explainer more focused
… I hadn't realized that you wanted to move stuff out of the string-meta document
… I still think the explainer is needed, but it needs to be way way way shorter than what we currently have
… I think some of the stuff that we have in the explainer is like an FAQ
… we could restructure string-meta a little
… I would have thought that if we have the introduction followed by some text that says this is the stuff you really need to read
… we don't necessarily have to move the rest of the stuff out
addison: I can make structural changes
… we don't have to move things out of there unless they're distracting
… the best practices section i think needs a massive rewrite in light of the changes that we want to make
… given that we're doing something different than the explainer originally did
… the rewrite of the explainer should make it much cleaner
r12a: the audience for the explainer is kind of different from the string-meta document
… I think it would be clear to be clear about what the audience is
… string-meta is kind of general purpose for anybody
… it has all the information that you would need
… the explainer is useful for TC39
… my question is what are we trying to do with the explainer?
… do we need more than one explainer?
addison: should these be articles?
r12a: yeah
addison: OK, so let's do this
… I think we need to change string-meta because that's the core document
… and redo the explainer so it's focused in the right way
… and the third thing is to decide a durable location
… I don't think a github markdown page is the right location
… maybe let's fix the explainer first
… explaining language metadata is relatively straightforward
… it's not a huge thing
… but explaining bidi seems to be a full-time job
r12a: the WG-specific stuff targeting a particular audience is perhaps enough for another explainer
addison: agreed
… in the current explainer there's a section that says what are "spillover effects"
… that whole thing probably just goes away
r12a: I was going to say that you do have some other useful stuff like what we want TC39 and Ecma to do
… that's really useful
addison: I'll take the action to fix the explainer
r12a: the first thing is to decide who's the audience for the explainer
… and whether we need one or more
… and then fix the explainer to meet the audience
addison: I agree
… we need to do some work on organizing the documents
Emphasis mark skipping
<addison> https://
addison: did everybody follow that thread?
<addison> https://
<addison> https://
addison: Ken and Robin Leroy replied to my email
… basically I asked Unicode if they wanted to keep track of character property for emphasis mark skipping
… and the answer was approximately no
… and more specifically, it sounds like someone could write a Unicode technical note
… someone in this case means CSS
r12a: Unicode folks might start more technical notes as well
… like how to implement Kashmiri
addison: the process is not clear
… and the learning curve is steep
r12a: note sure if it's that complicated
… they don't require a particular format
… you can publish an HTML page and link to it
Definition of 'string' revisited
<addison> w3c/
r12a: you can see the technical notes written by Norbert Lindenberg, for example
… just produce something similar to that
<addison> https://
addison: have a look and see what you think
… the difference here mainly is I pulled the mustard to the front
… which is our style
… and then the explanatory text
r12a: I thought we were going to say use USVString unless you need to use DOMString
addison: I'm reluctant to break that for the moment
… in the HTML space and the JS space, you pretty much want to use DOMStrings
… but everywhere else it's wrong
… is that the only thing that's wrong with this section?
r12a: it just seems kind of weird to dogmatically state the opposite of what we think really should be the case
… or make it clear this is a preliminary guideline based on the current TAG practice
addison: trying to fixing the linking in i18n-glossary
<r12a> https://
xfq: it could be a bug in ReSpec
addison: could be
xfq: if we want to link to it in other specs, we need to use class="export"
… like <dfn class="export">UTF-16</dfn>
Review 'needs-attention' issues
<addison> gb, list open issues from w3c/i18n-activity with label needs-attention
<gb> addison, sorry, I don't understand what you want me to do. Maybe try "help"?
<r12a> gb, list open issues from w3c/i18n-activity
<addison> gb, list open issues with label needs-attention from w3c/i18n-activity
<gb> addison, sorry, I don't understand what you want me to do. Maybe try "help"?
<addison> https://
<addison> w3c/i18n-activity#1758
<gb> Issue 1758 Reference for punycode-encoding of IDN (by w3cbot) [tracker] [needs-attention] [s:rdf-concepts]
<addison> w3c/
<gb> Issue 63 Reference for punycode-encoding of IDN (by domel) [i18n-tracker] [spec:substantive]
addison: do we need to change this to needs-resolution?
JcK: almost any time you talk about Punycode you're saying something wrong
… but I don't quite understand what the issue is here
<Bert> gb, list open issues with label needs-attention from REPO w3c/i18n-activity
<gb> Found issues in w3c/i18n-activity: #1758, #1560, #1361, #1026, #980, #809, #765, #590, #506, #404, #370, #259, #258, #219, #216, #98, #78, #46, #8
addison: RDF has a bunch of stuff about URL resolution
<addison> w3c/i18n-activity#1560
<gb> Issue 1560 support Unicode(or UTF-8 encoded) identifiers (by w3cbot) [close?] [tracker] [needs-attention] [s:wasm-core] [t:char_ranges] [t:markup_identifiers]
<addison> WebAssembly/
addison: this is an issue they created themselves, xfq discovered and tracked
… I don't think we have enough information to keep it open
xfq: do we have guidelines in specdev about Unicode identifiers?
addison: it's good to allow them to be non-ASCII
r12a: I'm not sure the WG decided against it
<addison> https://
r12a: it sounded more to me like there's not enough interest
… what's the status of the document?
xfq: https://
… https://
Transition request: w3c/