14:57:44 RRSAgent has joined #i18n 14:57:48 logging to https://www.w3.org/2024/11/19-i18n-irc 14:57:52 Meeting: I18N ⇔ CSS 14:57:58 agenda: https://www.w3.org/events/meetings/a1f2b55d-d2c7-40a1-a3e7-4c5eb70aa55e/20241119T070000/ 14:57:58 clear agenda 14:57:58 agenda+ Agenda 14:57:58 agenda+ Action Items 14:57:58 agenda+ Info Share and Progress Reports 14:57:58 agenda+ Review on-going issues 14:58:04 rrsagent, make log public 14:58:06 rrsagent, make minutes 14:58:07 I have made the request to generate https://www.w3.org/2024/11/19-i18n-minutes.html xfq 14:58:34 present+ 15:02:52 r12a has joined #i18n 15:04:47 no fantasai, florian, or himorin on the call yet 15:08:52 present+ r12a, atsushi, fantasai 15:08:57 scribe: xfq 15:08:59 agenda? 15:09:19 zakim, take up item 1 15:09:19 agendum 1 -- Agenda -- taken up [from agendabot] 15:09:49 - [ ] capitalise first letter: https://github.com/w3c/csswg-drafts/issues/11047 15:09:49 - [ ] left-leaning obliques: https://github.com/w3c/csswg-drafts/issues/9389#issuecomment-2407616997 15:09:49 - [ ] text align for ::marker https://w3c.github.io/i18n-drafts/questions/qa-upright-counters-in-vertical.html 15:09:50 https://github.com/w3c/csswg-drafts/issues/11047 -> Issue 11047 [css-text] Make first-letter work with inline text (by r12a) [css-pseudo-4] [css-text-4] [Agenda+ Later] 15:09:50 https://github.com/w3c/csswg-drafts/issues/9389 -> 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] 15:10:43 agenda+ capitalise first letter 15:10:48 agenda+ left-leaning obliques 15:10:57 agenda+ text align for ::marker 15:11:00 present+ florian 15:11:09 agenda? 15:11:14 zakim, close this item 15:11:14 agendum 1 closed 15:11:16 I see 6 items remaining on the agenda; the next one is 15:11:16 2. Action Items [from agendabot] 15:11:20 zakim, take up item 2 15:11:20 agendum 2 -- Action Items -- taken up [from agendabot] 15:11:41 https://github.com/w3c/i18n-actions/issues?q=is%3Aissue+is%3Aopen+label%3Acss 15:11:51 #120 15:11:54 https://github.com/w3c/i18n-actions/issues/120 -> Action 120 add dicussion document to i18n-discuss repo of seeking font metrics for various writing systems (on frivoal, fantasai) due 2024-09-24 15:12:26 florian: no pregress 15:13:16 #116 15:13:17 https://github.com/w3c/i18n-actions/issues/116 -> Action 116 sort out the various categories of things that get autospaced with koji (on frivoal, fantasai) due 2024-08-27 15:14:39 #11 15:14:39 https://github.com/w3c/i18n-actions/issues/11 -> Action 11 Triage all css properties to determine which are logical, physical, or na by default (on frivoal) due 18 Jul 2023 15:15:20 zakim, close this item 15:15:20 agendum 2 closed 15:15:21 I see 5 items remaining on the agenda; the next one is 15:15:21 3. Info Share and Progress Reports [from agendabot] 15:15:23 zakim, take up item 3 15:15:23 agendum 3 -- Info Share and Progress Reports -- taken up [from agendabot] 15:15:51 florian: there's been an issue filed on the ruby markup spec 15:16:10 ... which is interesting because it raises the question of the topic we hadn't covered yet 15:16:25 ... which is about having some kind of attribute to indicate how ruby should be read out 15:16:29 ... we've discussed this 15:16:38 ... Murata-san has a report exploring the question 15:16:45 ... but spec-wise, this wasn't covered yet 15:17:10 ... and there is now an issue against the spec asking for a solution in that space and proposing a solution 15:17:15 ... it's not been discussed yet 15:17:21 ... but it's been raised 15:17:34 ... my general intent is to be supportive of that direction 15:17:36 https://github.com/w3c/html-ruby/issues/24 15:17:37 https://github.com/w3c/html-ruby/issues/24 -> Issue 24 Add a way to indicate the semantics of ruby annotations (by jyasskin) 15:17:46 ... but it will be less mature than the rest of the spec 15:18:39 r12a: we have seen something else from jyasskin who is determined to find a way to open ruby up to other languages 15:18:56 ... and to use it for the Blissymbolics 15:19:13 ... as a working group we're supposed to reply to him 15:19:23 ... @@1 15:19:38 florian: what is Blissymbolics? 15:19:45 r12a: it's a pictographic language 15:19:51 ... it's used for a11y purposes 15:20:00 ... and basically you see pictures rather than words 15:20:36 florian: James Craig from Apple @@ is about whether the ruby is phonetic or semantic 15:21:23 ... back to the original topic, I don't think it can be included in the first batch of the REC 15:21:51 ... 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 15:22:02 ... I wouldn't spec it immediately 15:22:17 ... I completely agree with the problem space 15:22:55 xfq: valid use case, need to look deeper into how we solve this problem 15:23:17 zakim, close this item 15:23:17 agendum 3 closed 15:23:18 I see 4 items remaining on the agenda; the next one is 15:23:18 4. Review on-going issues [from agendabot] 15:23:25 agenda? 15:23:35 zakim, take up item 5 15:23:35 agendum 5 -- capitalise first letter -- taken up [from xfq] 15:23:45 https://github.com/w3c/csswg-drafts/issues/11047 15:23:46 https://github.com/w3c/csswg-drafts/issues/11047 -> Issue 11047 [css-text] Make first-letter work with inline text (by r12a) [css-pseudo-4] [css-text-4] [Agenda+ Later] 15:24:39 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 15:24:56 ... if the markup is a block, that's not a problem 15:25:24 ... you can uppercase it using ::first-letter 15:25:34 ... but if it's an inline element, you can't do that 15:25:41 ... so how could we make it happen? 15:26:05 ... the image gives you three instances 15:26:18 fantasai: I think that's a reasonable use case 15:26:26 ... I don't think it's particularly an i18n use case 15:26:38 ... allowing first letter on inline element is not unreasonable 15:26:48 ... but first letter is complicated to implement 15:27:11 ... so the main concern would be whether implemeneters would be willing to put in the time to make that work 15:27:31 florian: another point is @@2 15:28:55 ... I think it's largely a question of implementation difficulty 15:29:12 ... and because it's challenging, it brings back to the question of how important is this 15:29:16 ... because it is hard 15:29:20 r12a: OK 15:29:28 zakim, close this item 15:29:28 agendum 5 closed 15:29:29 I see 3 items remaining on the agenda; the next one is 15:29:29 4. Review on-going issues [from agendabot] 15:29:34 agenda? 15:29:37 zakim, take up item 6 15:29:37 agendum 6 -- left-leaning obliques -- taken up [from xfq] 15:29:47 https://github.com/w3c/csswg-drafts/issues/9389#issuecomment-2407616997 15:29:48 https://github.com/w3c/csswg-drafts/issues/9389 -> 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] 15:30:32 r12a: this is something we talked about a while ago 15:31:05 https://github.com/w3c/csswg-drafts/issues/8914#issue-1742061174 15:31:06 ... 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 15:31:06 https://github.com/w3c/csswg-drafts/issues/8914 -> 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)] 15:31:33 florian: can you rewind back to the beginning and not from a technical aspect, but from a needs aspect 15:32:00 r12a: so the use case is that scripts like N'Ko does not lean to the right at all in italics 15:32:14 ... they've decided that they wanted to lean to the left only 15:32:25 ... scripts like Arabic sometimes lean to the left 15:32:34 ... which is the reading direction 15:32:41 ... @@3 15:32:49 ... depends on user preference 15:33:07 ... the problem: browsers didn't support leaning to the left properly 15:33:24 florian: in order to properly address it 15:33:59 ... we need to fix the whole fallback system between italic and oblique and vice versa and synthesis and not synthesis and all of this 15:34:11 r12a: OK 15:34:25 ... fantasai, anything to add? 15:34:34 fantasai: no, not really 15:34:47 ... it's clear that we need to address these problems 15:34:59 ... I tagged it for the F2F agenda 15:35:14 ... if there's something specific that we need to take up 15:35:21 ... we can take it up eariler 15:35:28 zakim, close this item 15:35:28 agendum 6 closed 15:35:29 I see 2 items remaining on the agenda; the next one is 15:35:29 4. Review on-going issues [from agendabot] 15:35:30 agenda? 15:35:35 zakim, take up item 7 15:35:35 agendum 7 -- text align for ::marker -- taken up [from xfq] 15:35:37 https://w3c.github.io/i18n-drafts/questions/qa-upright-counters-in-vertical.html 15:36:04 r12a: this is an article that I put out for initial review by the WG 15:36:12 ... got a comment from Murata-san 15:36:27 ... which was not very clear as to what he was actually talking about 15:36:45 ... but he was saying something that I had noticed before 15:37:01 ... it depends on which browser you're using 15:37:32 ... I think Safari doesn't work at all if you want to use the text-combine-upright in the list marker 15:38:02 fantasai: it should probably following the vertical-align property rather than the text-align property 15:38:30 ... because when you use text-combine you get something that is effectively a glyph, right? 15:38:39 ... and then it is in line with the rest of the text 15:39:11 ... if it's not aligned properly, that's because it's not being correctly aligned with the rest of the content on @@ 15:39:33 r12a: I was assuming the marker box is a separate box and it's horizontal in this case 15:39:51 fantasai: it is a separate box, and it's kind of out of flow 15:40:09 ... I think it's a bug 15:40:14 r12a: how do we fix that? 15:40:32 fantasai: we make a test case and encourage people to submit patches 15:40:53 ... I think in general the positioning marker boxes is a little bit underdefined 15:41:06 ... so it doesn't surprise me that there are bugs there 15:41:56 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 15:42:15 fantasai: yes, if you're in a vertical writing mode 15:42:36 ... I think eventually vertical-align property should apply to markers as well 15:42:53 ... it's functioning like an inline box 15:43:04 ... just pulled out of the context of the rest of the line 15:43:18 ... used for superscript, subscript 15:43:48 r12a: that's really counterintuitive because I would expect vertical-align to move it upwards or downwards 15:44:03 fantasai: in vertical text, it's in the block axis 15:45:01 florian: I think we have a bug in browsers that don't let you target list markers for styling in terms of text orientation 15:45:31 ... I've had a different though related problem about numerical list markers in vertical text 15:45:52 ... and the text orientation I was getting for my list markers was not the one I wanted 15:46:11 ... because my text orientation was set on the text as a whole for what I wanted for the text 15:46:29 ... for the marker specifically, I wanted something different and couldn't get that 15:46:39 ... but I think that's an impl bug rather than a spec bug 15:47:14 https://github.com/w3c/csswg-drafts/issues/9788 15:47:14 https://github.com/w3c/csswg-drafts/issues/9788 -> Issue 9788 [css-pseudo][css-writing-modes] `text-orientation` and `::marker` (by frivoal) [css-pseudo-4] [css-writing-modes-4] [Needs Testcase (WPT)] 15:47:48 florian: Oriol is making the point that it's already specified that is should work 15:48:27 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 15:48:33 ... is that a fair summary? 15:48:57 florian: so currently they apply the text-combine-upright but just position it wrong? 15:49:26 r12a: it looks okay, but if you look at the example the second example from the bottom in Firefox 15:49:43 ... that's clearer because it's quite small numbers 15:49:58 ... if you make the numbers bigger, less of a problem 15:50:07 ... but it's still slightly a problem 15:50:16 ... as you can see in the bottom example 15:50:34 r12a: with the counter styles approach it's actually slightly better 15:50:45 ... it seems to center them pretty much above the line 15:51:41 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 15:51:54 r12a: it doesn't work at all in Safari 15:53:22 ... I can raise an issue against WebKit 15:53:28 https://bugs.webkit.org/show_bug.cgi?id=234705 15:53:31 fantasai: there's one already 15:54:47 xfq: need bug reports about the original issue? 15:54:56 r12a: yes 15:55:26 fantasai: it should be aligned using the baseline as the text normally is aligned 15:55:27 https://bugs.webkit.org/show_bug.cgi?id=204163 15:55:35 r12a: I intend to raise bugs for that 15:55:37 ... 15:55:44 s/... // 15:56:06 zakim, close this item 15:56:06 agendum 7 closed 15:56:07 I see 1 item remaining on the agenda: 15:56:07 4. Review on-going issues [from agendabot] 15:56:09 agenda? 15:57:07 Topic: AOB 15:57:28 https://www.w3.org/TR/jpan-lreq/#writing_mode 15:57:34 r12a: I've been working hard over the last several months to change the documents that we are producing in the language enablement arena 15:57:50 ... there's now a set of documents with a -lreq at the end 15:58:05 ... which have the links to info about the various topics that we're concerned with 15:58:08 ... example ^ 15:58:34 ... I found that WebKit bug if you go to the Japanese document 15:58:41 atsushi: thank you 15:58:59 r12a: you can get to them from the overall language enablement index 15:59:09 ... which is linked from the homepage 15:59:25 ... the link that I put into IRC links to a section about writing mode 15:59:59 rrsagent, make minutes 16:00:00 I have made the request to generate https://www.w3.org/2024/11/19-i18n-minutes.html xfq