Meeting minutes
Agenda Review
Action Items
<gb> Found actions in w3c/i18n-actions: #58, #57, #56, #55, #54, #53, #47, #43, #39, #35, #33, #18, #16, #12, #11, #8, #7, #5, #4
<addison> #58
<gb> Action 58 revise localizable-manifests in light of tpac conversation and new explainer (on aphillips) due 2023-11-09
<addison> https://
addison: I gave a lightning talk at the UTW
… about string meta
<addison> #57
<gb> Action 57 add localizable content definition to the glossary (on xfq) due 2023-11-09
<addison> #56
<gb> Action 56 check on permissions with w3ctag and follow up with plh on looking for notifications (on xfq) due 2023-11-02
<addison> #55
<gb> Action 55 work out new time slot for i18n/CSS call (on xfq) due 2023-11-01
<addison> xfq: enough answers to doodle poll, will propose time slot
https://
<addison> #54
<gb> Action 54 read Murata-san's ruby-t2s-req and Chinese requirements and Zaima and see what we're going to do (on xfq) due 2023-11-01
<addison> #53
<gb> Action 53 come up with a set of information CSS want the i18n group to provide support for generic font families (on frivoal, fantasai) due 2023-11-01
<addison> #47
<gb> Action 47 make the CSSWG aware of Warichu (on frivoal) due 2023-10-04
<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> #39
<gb> Action 39 develop best practice guidelines for name-like fields (on aphillips) due 2023-08-31
addison: I'm waiting on reviews
<addison> close #39
<gb> Closed action #39
<addison> #35
<gb> Action 35 make the edits of CSS #5478 (on fantasai) due 2023-08-30
<addison> #33
<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)
<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> #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)
addison: anything we can do to jiggle the handle on the respec action?
r12a: write some code
Info Share
r12a: someone sent me a document about Urdu
… it's time for me to create an Urdu Gap Analysis document
… and do some updates to the counter styles document as well
… although I have a number of questions about how that works
… the more I think about that, the more I wonder whether it's a sensible thing to do
… I've done several already
… it takes quite a while
… I'm thinking maybe not doing a layout requirements document
… but just point to my document
… the layout requirements document contains no technology specific information
r12a: my documents are dynamic
… they have all sorts of additional information which is maybe not appropriate to go in the lreq document
… the lreq document is an evergreen document that describes how the language works
… it's a big job, as xfq knows and atsushi knows
addison: is that something we could automate better?
r12a: no
… I'm not saying get rid of the ones that we have necessarily
… I'm just saying I don't think I'll try and write another lreq document
martin: there was one unconference session about IDN
<addison> https://
martin: IDNA 2008 and UTS #46
<gb> Action 46 [closed] read the string-meta explainer and consider the new approach addison proposes (on xfq, r12a) due 2023-09-28
martin: they still have different purposes
… but the essential difference that they had is mostly gone
addison: IETF has an exclusion process for characters
… and it's a long running process
… Mark Davis thinks that the exclusion process is a bad thing
martin: trying to catch up with new versions of Unicode is definitely something that I want to tell the idea of people to do
RADAR Review
<addison> https://
addison: we have no new incoming requests
… we have nothing in review
… vc-json-schema is moved over to Awaiting comment resolution
Generic Font Families
<addison> https://
r12a: this is a long standing issue
… there are some font styles or writing styles that you might be using in a particular language
… if the user doesn't have the font you specified, the browser is going to fall back
… the generics we have at the moment are sort of stylish
… like serif and sans-serif
… during Geek Week I updated all the fonts of macOS and Windows 11, and Noto and SIL
… I grouped those fonts into scripts and different writing styles
… Chris Lilley already proposed the addition of Kai as a generic fallback
… but there are things like rashi and so on
… this list is based on the system fonts and Noto fonts in particular
… for Hebrew there's not only rashi
… there are also cursive letters
… a bit further down, you can see that I'm suggesting that users should be able to define which font gets used for a particular generic
… just like you can choose what you want for serif and sans-serif at the moment
<addison> xfq: useful page and in right direction; chris lilley has already added some comments
martin: you showed this fonts dialogue
… if I choose Latin, I would still have these choices
… but what if I use Chinese
r12a: this is implementation specific and it's kind of up to the browsers to an extent
<r12a> https://
martin: what about Fangsong and Kai in Latin?
r12a: I don't really know the answer
martin: probably it would confuse most users in the Western Hemisphere if they see kai and nastaliq
… it's definitely the browser makers to figure out whether they want to do that
… if it's helpful to have Kai for Chinese and not for Latin
… then do we have that information to what extent can be provided or not
addison: it's not really about language
… it's about setting up what your fallback is
addison: what's the next step?
r12a: probably need to copy it to all of the language enablement groups
… it's getting quite a lot of attention from serious people on Mastodon
… I don't think whether CSS really need to set up a registry
… so what's been happening so far is that Chris Lilley is gonna add Kai and nastaliq
addison: should we formalize this more?
… this is just a wiki page at the moment
r12a: wiki makes it really easy to change things
addison: if our intention is to do a note eventually, we might want to start setting up a repo and a shortname
… maybe roll it around in your head for a week
r12a: OK, I'll do that
… I expect that we will add more than these styles eventually
… but people will have to make a strong case for it
… if you have a registry anyone could suggest stuff to it
… you'd end up with a bit of a mess
addison: having it in the spec means higher level of friction
… you can always make a registry later