Meeting minutes
<gb> Issue 11648 not found
<gb> Issue 1988 not found
<gb> Issue 1988 not found
<gb> Issue 11648 not found
Agenda Review
Action Items
<addison> https://
<addison> #160
<gb> Action 160 review graphemes in specdev and add balinese example and otherwise fix the text (on aphillips) due 2025-03-06
<addison> #159
<gb> Action 159 write up proposal for specdev char-string section, adding material that deals with the encoding interface et al (on aphillips) due 2025-02-27
addison: #159 is related to another agenda item
<addison> #157
<gb> Action 157 write glossary proposal identifying options and next steps for those options (on aphillips) due 2025-02-20
addison: #157 is on the agenda today
<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: #135, starting trading some Slack conversation with Manish, still pending
<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
addison: in a very short period of time the USA will switch to DST
<addison> https://
<addison> https://
r12a: did everybody read it and think it was okay?
<addison> (note to self: steal richard's version of the family emoji for specdev)
<r12a> https://
r12a: here's the direct link
… what I changed ^
[Discuss emoji issues in specdev]
<addison> https://
<addison> https://
Review RADAR
Pending Issue Review
<addison> https://
<gb> Issue 1988 not found
<gb> Issue 11648 not found
Specdev and "Typographic Unit" PR
addison: pending issues, nothing super exciting here, except the one with agenda+
… which I've added to the agenda
<addison> w3c/
<gb> Pull Request 153 Replace Bangla example, replace user-perceived character (by aphillips)
<addison> https://
addison: there are two primary changes
… we'll start with the first one, which is characters
… the goal here was to replace our use of grapheme and glyph and such with the term typographical unit
<addison> Specifications SHOULD use the term code point instead of the term 'character'. If the term 'character' is used, it MUST be explicitly defined to mean a Unicode code point. The term Unicode Scalar Value MAY also be used.
addison: or the term user perceived character with typographical unit
<addison> (the old: Specifications SHOULD explicitly define the term 'character' to mean a Unicode code point.)
nmccully: I'm wondering, did anyone raise concern that typographical unit is often used for measurement and not linguistic character
xfq: yes, people in clreq TF also raised this concern before
<addison> Specifications SHOULD explicitly define the term 'character' to mean a Unicode code point.
nmccully: I find it to be more opaque than grapheme cluster or linguistic character unit
<addison> https://
nmccully: typographic unit to me is a upm or a point or something like that
addison: that's fair
r12a: but we do mean something that is kind of vague and not clearly defined and may change in different places
… similar to the CSS definition
… the this is viewed from the user's point of view rather than from a machine point of view
nmccully: yeah, that's a good point
addison: you're trying to say grapheme cluster but not exactly Unicode's grapheme cluster because that turns out to be problematic sometimes
r12a: we're trying to get away from the implementation
… this could be just writing on a piece of paper
nmccully: ok, so character unit
r12a: yeah, but then it sounds like a single code point
<addison> https://
addison: if you look at example 7, we go back to the Hindi thing and we show the syllables as well as the syllables typographical units with one of them highlighted and we show that that's broken into underlying characters
nmccully: I think I would call that a typographic character
… it's unit in the other sense of the term
r12a: which is probably the most widespread use of the term
nmccully: for British people
nmccully: what's wrong with 'character'?
nmccully: I've tried not to say a 'Unicode character' because character can to some people mean accented E or whatever and it's more than one Unicode code point
nmccully: the other thing that bothers me is you're talking about typographic when you want to refer to writing too
<addison> 'visual unit'
addison: visible text unit?
https://
addison: we don't expect people to use this term, whatever term we choose
<addison> https://
xfq: our LE index already uses this term as its section name
addison: should we try visible text units?
nat: it's a bit better for me
addison: all right, I will make that change and try this again
… let me point out the other section that got changed here
… in 6.5 Truncating or limiting the length of strings
r12a: I think the example could be better if you went one byte further
… in the English I would say "I can eat glass,"
addison: this needs more work
… good suggestions
… maybe I'll unbox the example and just have it be plain text
<addison> In an earlier example (Example 9), the composed "family" emoji sequence "👨👩👧👧" consists of 7 code points. The byte limit of 15 truncates after the second family member: "👨👩".
<gb> Issue 11648 not found
<gb> Issue 1988 not found
How to make list markers stand upright in vertical text
<r12a> https://
r12a: this is about the whole article, but I've zoomed in on a particular place ^
… where I've just made some changes
… I had only one outstanding issue after sending this out for review
… it was to do with the properties that you can apply
… the CSS styles that you can apply to the ::marker pseudo element
… originally I had just said CSS allows you to apply these properties and that was it
… Blink allows you to do more properties than that
… and some of these properties are not supported in Safari
<addison> i%3E%0A%3Cli%20id%3D%22fontfamily%22%3Efont-family%3C%2Fli%3E%0A%3Cli%20id%3D%22direction%22%3Edirection%3C%2Fli%3E%0A%3Cli%20id%3D%22textshadow%22%3Etext-shadow%3C%2Fli%3E%0A%3Cli%20id%3D%22texttransform%22%3Etext-transform%3C%2Fli%3E%0A%3C%2Fol%3E&css=.test%20li%20%7B%20list-style-type%3A%20lower-alpha%3B%20margin-inline-start%3A%203rem%3B%20%7D%
<addison> 0A%23color%3A%3Amarker%20%7B%20color%3A%20lightgreen%3B%20%7D%0A%23content%3A%3Amarker%20%7B%20content%3A%20%27%40.%20%27%3B%20%7D%0A%23fontstyle%3A%3Amarker%20%7B%20font-style%3A%20italic%3B%20%7D%0A%23fontvariant%3A%3Amarker%20%7B%20font-variant%3A%20small-caps%3B%20%7D%0A%23fontweight%3A%3Amarker%20%7B%20font-weight%3A%20bold%3B%20%7D%0A%23fontf
<addison> amily%3A%3Amarker%20%7B%20font-family%3A%20Consolas%2C%20%27Andale%20Mono%27%2C%20%27Lucida%20Console%27%2C%20%27Lucida%20Sans%20Typewriter%27%2C%20Monaco%2C%20%27Courier%20New%27%2C%20%27monospace%27%3B%20%7D%0A%23direction%3A%3Amarker%20%7B%20direction%3A%20rtl%3B%20%7D%0A%23textshadow%3A%3Amarker%20%7B%20text-shadow%3A%200%200%205px%3B%20%7D%0A%
<addison> 23texttransform%3A%3Amarker%20%7B%20text-transform%3A%20uppercase%3B%20%7D%0A&fontSize=36&width=500&height=500&a=Various%20styles%20indicated%20in%20the%20CSS%20spec%20are%20supported%20for%20%3A%3Amarker.&i=Test%20passes%20if%20you%20see%20the%20expected%20styling%20for%20each%20line.
r12a: there's a link that goes to a test that I put together this morning which you might find of interest if you click on that link
… that's the latest edition
… otherwise I'm hoping that this article is now stable enough
… to publish
nmccully: the only objections I would raise are to encourage the particular choice of numbering you've done for vertical is IMO not the mainstream
… I think jlreq plans to talk about this in terms of what is more traditional
<gb> Issue 11648 not found
<gb> Issue 1988 not found
r12a: good suggestion, I can add that
addison: anybody object to our publishing this?
… right, thank you, r12a, for all your work on this
… this is really good stuff as usual
<r12a> https://
r12a: just so you're aware, there's another one on the boil that might take as long as well
… which is about the q element
… I haven't uploaded the latest version
… fantasai and florian had a long conversation about that and came up with "well, this is what the CSS ought to look like"
… but it's sort of future
… it's not even in the spec yet
… with the match-parent and stuff like that and auto values
… so I have to figure out what you can do in the meantime to make this work
… and I'm not quite sure how to do it
… but I wanted to let you know that I'm working on that
… I should update the draft
nmccully: Korean @@ French not using thin space etc.
r12a: I should redo that example
I18N Glossary Options
<addison> https://
addison: I had an action to look at different ways we've been discussing what to do with the i18n glossary
… and pulling together some different options
… four things I could think of based on our previous conversation for what to do with the glossary
… see ^
… the history is we have this glossary document, and we tell people to link to terms in it when they need it
… like you need to say 'locale' and your spec has nothing to do with locales but you need to link to a def
… link to ours, it's exported
… it's easy to get
… it works automatically in respec and bikeshed
… but those tools produce a warning when you do that in a normative block because our glossary is a note
… but we would like to provide people a way to use our jargon 'code point'
… effectively without having to copy the def into every single spec
<addison> #155
<gb> CLOSED Action 155 review glossary definitions for normativity or candidates for normativity (on aphillips) due 2025-01-23
addison: and when we change the def, go hunt all those people down and fix it
r12a: I think part of the homework here was actually to derive a list of which of these things needed to be normative
addison: one of the things that's interesting is the Unicode glossary has no normativity
xfq: because the Unicode Core Spec defines a lot of the terms
addison: it used to be the TUS was not something you could access from the web, and now that it is
… one potential option E would be specdev does a lot of this work
xfq: specdev is also a note
addison: yeah, but it's also the best practices document and we have mustard in it
… it also straddles the line
… maybe it doesn't fix this entirely
… but it solves a couple of problems, one of them being that we would like to deprecate charmod fundamentals
<gb> Issue 1988 not found
<gb> Issue 11648 not found
local fonts vs privacy: activity#1988 (css#11648)
<addison> i18n-activity#1988
<gb> Issue 1988 [css-fonts-4] Detection-prevention approach to the local font privacy issue (by w3cbot) [pending] [tracker] [s:css-fonts] [wg:css] [Agenda+]
<addison> w3c/csswg-drafts#11648
<gb> Issue 11648 [css-fonts] Detection-prevention approach to the local font privacy issue (by noamr) [css-fonts-4] [i18n-tracker] [privacy-tracker]
xfq: we should link to this doc somewhere in github
addison: I wanted to bring this up ^
… new proposal for the local font privacy issue
r12a: it's now like you're reading a book to get your head around this issue
… Chris put a list of links to issues on this topic
… he had an explainer that we were using
… in the TPAC discussion
AOB?
nmccully: we're really at a crossroads where Unicode being inadequate for typography and depending on fonts and fonts having such chaos in terms of how they support each language
… for our use case and our apps are suffering greatly by not having access to the fonts in the system