Meeting minutes
<r12a> no fantasai, florian, or himorin on the call yet
Agenda
<r12a> - [ ] capitalise first letter: w3c/
<r12a> - [ ] left-leaning obliques: w3c/
<r12a> - [ ] text align for ::marker https://
<gb> Issue 11047 [css-text] Make first-letter work with inline text (by r12a) [css-pseudo-4] [css-text-4] [Agenda+ Later]
<gb> Issue 9389 [css-fonts] avoid fallback from oblique to italic (by frivoal) [css-fonts-4] [i18n-needs-resolution] [Needs Testcase (WPT)] [i18n-alreq] [i18n-afrlreq] [i18n-hlreq]
Action Items
https://
#120
<gb> Action 120 add dicussion document to i18n-discuss repo of seeking font metrics for various writing systems (on frivoal, fantasai) due 2024-09-24
florian: no pregress
#116
<gb> Action 116 sort out the various categories of things that get autospaced with koji (on frivoal, fantasai) due 2024-08-27
#11
<gb> Action 11 Triage all css properties to determine which are logical, physical, or na by default (on frivoal) due 18 Jul 2023
Info Share and Progress Reports
florian: there's been an issue filed on the ruby markup spec
… which is interesting because it raises the question of the topic we hadn't covered yet
… which is about having some kind of attribute to indicate how ruby should be read out
… we've discussed this
… Murata-san has a report exploring the question
… but spec-wise, this wasn't covered yet
… and there is now an issue against the spec asking for a solution in that space and proposing a solution
… it's not been discussed yet
… but it's been raised
… my general intent is to be supportive of that direction
<florian> w3c/
<gb> Issue 24 Add a way to indicate the semantics of ruby annotations (by jyasskin)
florian: but it will be less mature than the rest of the spec
r12a: we have seen something else from jyasskin who is determined to find a way to open ruby up to other languages
… and to use it for the Blissymbolics
… as a working group we're supposed to reply to him
… @@1
florian: what is Blissymbolics?
r12a: it's a pictographic language
… it's used for a11y purposes
… and basically you see pictures rather than words
florian: James Craig from Apple @@ is about whether the ruby is phonetic or semantic
… back to the original topic, I don't think it can be included in the first batch of the REC
… now, we might want to have everything in the ED and then split out a level 1 and a level 2 and keep that for the later
… I wouldn't spec it immediately
… I completely agree with the problem space
xfq: valid use case, need to look deeper into how we solve this problem
capitalise first letter
<gb> Issue 11047 [css-text] Make first-letter work with inline text (by r12a) [css-pseudo-4] [css-text-4] [Agenda+ Later]
r12a: here's a situation that I came across in real life, where I wanted to basically be able to uppercase the beginning of some text that was surrounded by markup
… if the markup is a block, that's not a problem
… you can uppercase it using ::first-letter
… but if it's an inline element, you can't do that
… so how could we make it happen?
… the image gives you three instances
fantasai: I think that's a reasonable use case
… I don't think it's particularly an i18n use case
… allowing first letter on inline element is not unreasonable
… but first letter is complicated to implement
… so the main concern would be whether implemeneters would be willing to put in the time to make that work
florian: another point is @@2
… I think it's largely a question of implementation difficulty
… and because it's challenging, it brings back to the question of how important is this
… because it is hard
r12a: OK
left-leaning obliques
<r12a> w3c/
<gb> Issue 9389 [css-fonts] avoid fallback from oblique to italic (by frivoal) [css-fonts-4] [i18n-needs-resolution] [Needs Testcase (WPT)] [i18n-alreq] [i18n-afrlreq] [i18n-hlreq]
r12a: this is something we talked about a while ago
<r12a> https://
r12a: that we need to be able to make obliques lean to the left and there were a bunch of problems, florian sort of split the thing into multiple issues
<gb> Issue 8914 [css-fonts] It should be possible to slant glyphs to the left for italics/oblique (by r12a) [css-fonts-4] [Needs Edits] [i18n-tracker] [Needs Testcase (WPT)]
florian: can you rewind back to the beginning and not from a technical aspect, but from a needs aspect
r12a: so the use case is that scripts like N'Ko does not lean to the right at all in italics
… they've decided that they wanted to lean to the left only
… scripts like Arabic sometimes lean to the left
… which is the reading direction
… @@3
… depends on user preference
… the problem: browsers didn't support leaning to the left properly
florian: in order to properly address it
… we need to fix the whole fallback system between italic and oblique and vice versa and synthesis and not synthesis and all of this
r12a: OK
… fantasai, anything to add?
fantasai: no, not really
… it's clear that we need to address these problems
… I tagged it for the F2F agenda
… if there's something specific that we need to take up
… we can take it up eariler
text align for ::marker
<r12a> https://
r12a: this is an article that I put out for initial review by the WG
… got a comment from Murata-san
… which was not very clear as to what he was actually talking about
… but he was saying something that I had noticed before
… it depends on which browser you're using
… I think Safari doesn't work at all if you want to use the text-combine-upright in the list marker
fantasai: it should probably following the vertical-align property rather than the text-align property
… because when you use text-combine you get something that is effectively a glyph, right?
… and then it is in line with the rest of the text
… if it's not aligned properly, that's because it's not being correctly aligned with the rest of the content on @@
r12a: I was assuming the marker box is a separate box and it's horizontal in this case
fantasai: it is a separate box, and it's kind of out of flow
… I think it's a bug
r12a: how do we fix that?
fantasai: we make a test case and encourage people to submit patches
… I think in general the positioning marker boxes is a little bit underdefined
… so it doesn't surprise me that there are bugs there
r12a: if we do what you're suggesting, I guess it's that by default all browsers should center the text-combine-upright stuff with the text below it
fantasai: yes, if you're in a vertical writing mode
… I think eventually vertical-align property should apply to markers as well
… it's functioning like an inline box
… just pulled out of the context of the rest of the line
… used for superscript, subscript
r12a: that's really counterintuitive because I would expect vertical-align to move it upwards or downwards
fantasai: in vertical text, it's in the block axis
florian: I think we have a bug in browsers that don't let you target list markers for styling in terms of text orientation
… I've had a different though related problem about numerical list markers in vertical text
… and the text orientation I was getting for my list markers was not the one I wanted
… because my text orientation was set on the text as a whole for what I wanted for the text
… for the marker specifically, I wanted something different and couldn't get that
… but I think that's an impl bug rather than a spec bug
<gb> Issue 9788 [css-pseudo][css-writing-modes] `text-orientation` and `::marker` (by frivoal) [css-pseudo-4] [css-writing-modes-4] [Needs Testcase (WPT)]
florian: Oriol is making the point that it's already specified that is should work
r12a: what I'm hearing is that I need to write bug reports to the browsers and say could you please center these things better when you display them
… is that a fair summary?
florian: so currently they apply the text-combine-upright but just position it wrong?
r12a: it looks okay, but if you look at the example the second example from the bottom in Firefox
… that's clearer because it's quite small numbers
… if you make the numbers bigger, less of a problem
… but it's still slightly a problem
… as you can see in the bottom example
r12a: with the counter styles approach it's actually slightly better
… it seems to center them pretty much above the line
florian: it would be interesting to try and isolate whether the lack of alignment is coming from the character and the fonts that are being used or the mechanism
r12a: it doesn't work at all in Safari
I can raise an issue against WebKit
<fantasai> https://
fantasai: there's one already
xfq: need bug reports about the original issue?
r12a: yes
fantasai: it should be aligned using the baseline as the text normally is aligned
<r12a> https://
r12a: I intend to raise bugs for that
…
AOB
<r12a> https://
r12a: I've been working hard over the last several months to change the documents that we are producing in the language enablement arena
… there's now a set of documents with a -lreq at the end
… which have the links to info about the various topics that we're concerned with
… example ^
… I found that WebKit bug if you go to the Japanese document
atsushi: thank you
r12a: you can get to them from the overall language enablement index
… which is linked from the homepage
… the link that I put into IRC links to a section about writing mode