12:57:48 RRSAgent has joined #i18n 12:57:52 logging to https://www.w3.org/2024/01/16-i18n-irc 12:57:55 Meeting: I18N ⇔ CSS 12:58:11 present+ 12:58:19 scribe: xfq 12:59:58 present+ 13:00:27 present+ atsushi 13:00:55 present+ r12a 13:01:39 regrets: fantasai 13:02:51 atsushi has joined #i18n 13:02:54 agenda+ ruby 13:03:03 Topic: Ruby 13:04:53 florian: hoping to work on the ruby document shortly 13:05:08 ... Firefox and Kindle implements the rb element 13:05:22 ... I believe we only have one impl of the rtc element at the moment 13:05:32 ... the markup side is very simple 13:05:46 ... I don't know how to test with Kindle 13:05:54 Addison should know how to test with Kindle 13:06:01 ... if one of you knows that might come in handy 13:06:12 ... otherwise it will be harder to prove that we do have 2 impls 13:06:44 ... hopefully we will have a spec that supports tabular markup for ruby 13:08:08 r12a: Addison will certainly know how to test for Kindle 13:08:23 ... I don't know whether we can do JS-vased testing like wpt 13:08:46 florian: for something like CSS Ruby Layout there's full of corner cases 13:09:03 ... it would be very annoying to test it manually because of the number of things you have to test 13:09:13 ... for the markup, there isn't all that much to test 13:09:27 r12a: part of the question will be what are we actually testing 13:09:38 ... are we testing the DOM elements? 13:10:06 florian: HTML spec is not specific about what kind of layout is appropriate 13:10:23 ... the exact layout is a question for CSS 13:10:49 ... any visual rendering as long as it demonstrates the association, I think that should be good enough 13:11:04 r12a: in terms of what goes into the spec and what doesn't go into the spec 13:11:13 ... given that rtc may or may not be supported 13:11:20 ... I think we need to be a little careful 13:11:51 ... another alternative is to keep it in the spec, but put it at-risk 13:12:15 florian: spec-wise they are all in one place 13:12:38 ... what also will need to happen is to make some pull requests against the WHATWG 13:12:42 ... to sync them a bit 13:13:03 ... they won't accept any new features until multiple browsers are do it 13:13:42 ... but sending them some PRs to shrink it to the subset of things that actually exist so that we can extend it here rather than contradict it here 13:13:50 ... I'll try to make those PRs happen 13:14:18 ... I also want the accessibility mapping and ARIA work 13:14:28 q+ 13:14:34 ... if we make our rb and rtc become valid elements 13:14:45 ... we will need to say something about them 13:14:56 ... I feel like there are 2 stages 13:15:10 ... stage 1 is we know that double reading is bad and we need to improve 13:15:23 s/stage 1/a stage/ 13:15:52 florian: but there's probably an earlier stage like we merely acknowledge these elements exist 13:16:22 ... @@fall back to linear rp@@ 13:16:48 ... if you linearize Chinese for example, you don't want the pinyin for Xi'an to become Xian 13:17:09 ... we could just use rp to put an apostrophe in the middle 13:17:20 ... I'm not sure I want to propose that just yet 13:17:37 ... but the idea intrigues me enough 13:17:45 r12a: it's extremely messy 13:18:10 ... I think the thing that we will probably need to look at is how much of that can be done by CSS as opposed to markup 13:18:33 florian: with text selectors you probably could get somewhere but we don't have those 13:18:47 r12a: you could also put quote marks in the pinyin, I suppose 13:19:25 florian: if you want to put it inline, you can do that today already 13:19:29 ... as Firefox works 13:19:46 ... what could be nice enough is that if you don't inline it, @@ 13:20:45 ... do you think rp should actually disappear some more or do you think it needs to stick around and therefore we could explore more interesting ways to use it? 13:20:49 r12a: I don't know the answer 13:20:56 ... I don't use it much myself 13:22:09 Related: https://github.com/w3c/csswg-drafts/issues/5997 13:22:09 https://github.com/w3c/csswg-drafts/issues/5997 -> Issue 5997 [css-ruby] Handling apostrophes in pinyin (by frivoal) [i18n-tracker] [i18n-clreq] [css-ruby-2] 13:22:50 florian: @@ 13:24:26 florian: do we want an attribute for distinguishing phonetic/semantic/translation information? 13:24:34 ... I'm kind of leaning that way 13:24:49 ... I'm not proposing that we solve this just yet 13:25:34 ... there are probably some variants like if you mark the phonetic annotation as being in a different language than the base text 13:26:00 ... Japanese textbooks for learning Chinese, for example 13:26:14 ... which group should we explore that? 13:26:22 ... obviously it's i18n related 13:26:41 ... should this be in a joint group with the markup people and a joint group with the a11y people? 13:27:03 r12a: I suspect that if we involve Murata-san, that will bring in the a11y folks 13:28:07 florian: HTML charter end in June 13:28:22 r12a: ruby is one reason for keeping the group 13:28:34 ... plh will find some place for us to put the ruby spec 13:29:16 florian: a long while ago, I think we talked about maybe publishing a last version of simple-ruby before abandoning it 13:29:22 ... I don't think that happened 13:29:42 atsushi: I believe Kida-san will coordinate this 13:29:48 ... I need to ping him 13:30:29 xfq: if we abandon it, where will the content go? 13:30:56 florian: I don't think it was meant to be something that needs to be maintained long term and that needs to be implemented 13:31:05 ... it describes an approach 13:31:21 ... which I think is informative for people who are learning about ruby layout 13:31:55 gb has joined #i18n 13:32:48 atsushi: @@ 13:33:07 florian: I don't remember exactly what we did about the terminology thing 13:33:26 ... there are many cases it's left up to the implementation 13:33:43 ... if you talk to an expert about ruby, they might know what they want 13:34:12 ... I think simple-ruby is a useful document 13:34:29 ... it gives them an example of a reasonable way to do things 13:34:47 ... and they can figure out how to map to the useful parts of that over to CSS if they want to 13:35:00 ... jlreq gives you so many variants 13:35:05 ... which is too big 13:35:18 ... I think simple-ruby is fairly self-contained 13:35:37 ... even if it uses different terminology, maybe it's not that bad 13:36:30 atsushi: we might want to define the terminology as categories semantically 13:36:43 ... not the exact characters 13:36:50 florian: I'm not sure 13:36:55 ... they're not perfect 13:37:07 ... but they have become familiar over the last 20 years or so 13:37:16 ... they're mentioned in so many documents 13:37:38 ... we could rewrite all of it, it might be clearer at the end 13:37:53 ... but there are so many documents talking about this 13:38:00 ... not only W3C 13:38:04 r12a: I agree 13:38:42 ... if you do rename things people may still want to find out about ruby by searching for jukugo ruby 13:38:56 atsushi: Kida-san will follow up re simple-ruby 13:39:15 https://github.com/w3c/i18n-actions/issues?q=is%3Aissue+is%3Aopen+label%3Acss 13:39:32 Topic: Action Items 13:40:01 #53 13:40:02 https://github.com/w3c/i18n-actions/issues/53 -> 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 13:40:24 xfq: do we still want to keep this open, or do we continue to discuss this in the CSS issues? 13:41:19 xfq: let's keep this open 13:41:24 https://github.com/w3c/csswg-drafts/issues/7183 -> Issue 7183 [css-text-4] Make autospace a property, rather than a value of text-spacing (by r12a) [css-text-4] [Commenter Response Pending] [i18n-needs-resolution] [i18n-jlreq] [i18n-clreq] 13:41:35 Topic: [css-text-4] Make autospace a property, rather than a value of text-spacing 13:42:01 r12a: Elika asked me about this a few days ago 13:42:27 ... this is my first day back and I have highlighted in in my list of 1,000 unread emails that I have to go through 13:42:44 Topic: GitHub issues 13:43:00 https://github.com/w3c/csswg-drafts/issues/8511 13:43:01 https://github.com/w3c/csswg-drafts/issues/8511 -> Issue 8511 [css-text-4] text-autospace: what gets copied? (by fantasai) [css-text-4] [Agenda+] [i18n-tracker] [i18n-jlreq] [i18n-clreq] [i18n-eurlreq] [Agenda+ i18n] 13:43:59 florian: I think we have somewhat contradictory point in the github discussion 13:44:34 ... I think we have both an almost consensus that we should copy the transformed output, except that the clreq editors thinks the other way 13:44:55 r12a: I thought we all agreed that we would not copy the space 13:45:05 ... I guess I need to reread this 13:45:17 florian: some of the conversation might not be written 13:46:43 ... I think there are at least some @@ 13:46:49 xfq: @@ 13:47:30 r12a: most browsers convert non-breaking spaces to normal spaces 13:47:37 ... that's really annoying 13:47:45 ... Mac does that 13:47:49 florian: that's not nice 13:48:30 ... maybe depending on whether you're replacing or adding 13:48:45 xfq: I'm a bit concerned that @@ 13:49:11 r12a: it also worries me a little that we're using the browser output as a tool to correct the copy&paste 13:49:18 ... it's not really supposed to do that 13:49:31 florian: there are so many ways of thinking about this 13:49:46 ... if you type French in Word 13:50:11 ... at editing time it will insert the relevant non-breaking spaces 13:50:28 ... nobody ever types these things because they magically appear where you need them 13:51:01 ... and if you're in a Facebook comment thread you also don't remember to take them because you never typed them 13:51:12 ... and Facebook doesn't add them for you at editing time at least 13:51:42 r12a: we can continue discuss in the thread 13:51:55 ... also drag in the CSSWG and the i18n WG 13:52:51 action: r12a to add some comments to CSS #8511 13:52:53 Created -> action #67 https://github.com/w3c/i18n-actions/issues/67 13:53:14 https://github.com/w3c/csswg-drafts/issues/7577 13:53:15 https://github.com/w3c/csswg-drafts/issues/7577 -> Issue 7577 [css-values-4][css-writing-modes-4] Revisit decision to use 永 instead of 水 as the ic unit (by ziyunfei) [css-values-4] [i18n-tracker] [i18n-jlreq] [i18n-clreq] [i18n-klreq] [Agenda+ i18n] 13:53:53 florian: as you may remember CSS uses the water ideogram to base some calculation of font metrics in a number of cases 13:54:39 ... there were a bunch of people say that's wrong because in traditional calligraphy the reference character is eternity, not water 13:54:49 ... we need to fix this 13:55:05 ... another proposal is to use ideographic space 13:55:13 ... I'm not sure what to do here 13:55:41 ... because I was completely unconvinced that switching from water to eternity did anything useful 13:55:57 ... is it too late? is it practical? 13:56:18 ... maybe this group can weigh in? 13:56:40 r12a: I suppose the key question is does U+3000 change size in proportional fonts 13:57:07 florian: would it be reliable and would it be a representative? 13:57:33 atsushi: including Hiragana, Katakanta, and punctuation marks 13:57:56 ... in jlreq meetings, people mentioned that there are three kind of proportional fonts in Japan 13:58:03 ... one fills the embox 13:58:12 ... the other two doesn't fill the embox 13:58:48 ... IIRC U+3000 is set to the same width of Hiragana/Katakana and the width could change in proportional fonts 13:59:14 florian: maybe we should look at a sample of actual fonts and see what that does 13:59:52 cf. https://lists.w3.org/Archives/Public/public-i18n-japanese/2023OctDec/att-0280/20231024-fonts.jpg 14:00:17 ... possibly an alternative is to use water, if there is not water, before falling back to the next font, look at U+3000 14:01:10 r12a: is the ic unit actually useful if you have proportional fonts? 14:01:10 florian: as an approximate one, yes 14:01:10 ... the same way as the ch unit 14:04:41 ... I don't know how to resolve this 14:04:45 rrsagent, make minutes 14:04:46 I have made the request to generate https://www.w3.org/2024/01/16-i18n-minutes.html xfq 14:04:58 rrsagent, make log public 14:05:00 rrsagent, make minutes 14:05:01 I have made the request to generate https://www.w3.org/2024/01/16-i18n-minutes.html xfq