Meeting minutes
Ruby
florian: hoping to work on the ruby document shortly
… Firefox and Kindle implements the rb element
… I believe we only have one impl of the rtc element at the moment
… the markup side is very simple
… I don't know how to test with Kindle
<r12a> Addison should know how to test with Kindle
florian: if one of you knows that might come in handy
… otherwise it will be harder to prove that we do have 2 impls
… hopefully we will have a spec that supports tabular markup for ruby
r12a: Addison will certainly know how to test for Kindle
… I don't know whether we can do JS-vased testing like wpt
florian: for something like CSS Ruby Layout there's full of corner cases
… it would be very annoying to test it manually because of the number of things you have to test
… for the markup, there isn't all that much to test
r12a: part of the question will be what are we actually testing
… are we testing the DOM elements?
florian: HTML spec is not specific about what kind of layout is appropriate
… the exact layout is a question for CSS
… any visual rendering as long as it demonstrates the association, I think that should be good enough
r12a: in terms of what goes into the spec and what doesn't go into the spec
… given that rtc may or may not be supported
… I think we need to be a little careful
… another alternative is to keep it in the spec, but put it at-risk
florian: spec-wise they are all in one place
… what also will need to happen is to make some pull requests against the WHATWG
… to sync them a bit
… they won't accept any new features until multiple browsers are do it
… 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
… I'll try to make those PRs happen
… I also want the accessibility mapping and ARIA work
… if we make our rb and rtc become valid elements
… we will need to say something about them
… I feel like there are 2 stages
… a stage is we know that double reading is bad and we need to improve
florian: but there's probably an earlier stage like we merely acknowledge these elements exist
… @@fall back to linear rp@@
… if you linearize Chinese for example, you don't want the pinyin for Xi'an to become Xian
… we could just use rp to put an apostrophe in the middle
… I'm not sure I want to propose that just yet
… but the idea intrigues me enough
r12a: it's extremely messy
… 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
florian: with text selectors you probably could get somewhere but we don't have those
r12a: you could also put quote marks in the pinyin, I suppose
florian: if you want to put it inline, you can do that today already
… as Firefox works
… what could be nice enough is that if you don't inline it, @@
… 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?
r12a: I don't know the answer
… I don't use it much myself
Related: w3c/
<gb> Issue 5997 [css-ruby] Handling apostrophes in pinyin (by frivoal) [i18n-tracker] [i18n-clreq] [css-ruby-2]
florian: @@
florian: do we want an attribute for distinguishing phonetic/semantic/translation information?
… I'm kind of leaning that way
… I'm not proposing that we solve this just yet
… there are probably some variants like if you mark the phonetic annotation as being in a different language than the base text
… Japanese textbooks for learning Chinese, for example
… which group should we explore that?
… obviously it's i18n related
… should this be in a joint group with the markup people and a joint group with the a11y people?
r12a: I suspect that if we involve Murata-san, that will bring in the a11y folks
florian: HTML charter end in June
r12a: ruby is one reason for keeping the group
… plh will find some place for us to put the ruby spec
florian: a long while ago, I think we talked about maybe publishing a last version of simple-ruby before abandoning it
… I don't think that happened
atsushi: I believe Kida-san will coordinate this
… I need to ping him
xfq: if we abandon it, where will the content go?
florian: I don't think it was meant to be something that needs to be maintained long term and that needs to be implemented
… it describes an approach
… which I think is informative for people who are learning about ruby layout
atsushi: @@
florian: I don't remember exactly what we did about the terminology thing
… there are many cases it's left up to the implementation
… if you talk to an expert about ruby, they might know what they want
… I think simple-ruby is a useful document
… it gives them an example of a reasonable way to do things
… and they can figure out how to map to the useful parts of that over to CSS if they want to
… jlreq gives you so many variants
… which is too big
… I think simple-ruby is fairly self-contained
… even if it uses different terminology, maybe it's not that bad
atsushi: we might want to define the terminology as categories semantically
… not the exact characters
florian: I'm not sure
… they're not perfect
… but they have become familiar over the last 20 years or so
… they're mentioned in so many documents
… we could rewrite all of it, it might be clearer at the end
… but there are so many documents talking about this
… not only W3C
r12a: I agree
… if you do rename things people may still want to find out about ruby by searching for jukugo ruby
atsushi: Kida-san will follow up re simple-ruby
https://
Action Items
#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
xfq: do we still want to keep this open, or do we continue to discuss this in the CSS issues?
xfq: let's keep this open
<gb> 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]
[css-text-4] Make autospace a property, rather than a value of text-spacing
r12a: Elika asked me about this a few days ago
… 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
GitHub issues
<gb> 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]
florian: I think we have somewhat contradictory point in the github discussion
… I think we have both an almost consensus that we should copy the transformed output, except that the clreq editors thinks the other way
r12a: I thought we all agreed that we would not copy the space
… I guess I need to reread this
florian: some of the conversation might not be written
… I think there are at least some @@
xfq: @@
r12a: most browsers convert non-breaking spaces to normal spaces
… that's really annoying
… Mac does that
florian: that's not nice
… maybe depending on whether you're replacing or adding
xfq: I'm a bit concerned that @@
r12a: it also worries me a little that we're using the browser output as a tool to correct the copy&paste
… it's not really supposed to do that
florian: there are so many ways of thinking about this
… if you type French in Word
… at editing time it will insert the relevant non-breaking spaces
… nobody ever types these things because they magically appear where you need them
… and if you're in a Facebook comment thread you also don't remember to take them because you never typed them
… and Facebook doesn't add them for you at editing time at least
r12a: we can continue discuss in the thread
… also drag in the CSSWG and the i18n WG
ACTION: r12a to add some comments to CSS #8511
<gb> Created action #67
<gb> 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]
florian: as you may remember CSS uses the water ideogram to base some calculation of font metrics in a number of cases
… there were a bunch of people say that's wrong because in traditional calligraphy the reference character is eternity, not water
… we need to fix this
… another proposal is to use ideographic space
… I'm not sure what to do here
… because I was completely unconvinced that switching from water to eternity did anything useful
… is it too late? is it practical?
… maybe this group can weigh in?
r12a: I suppose the key question is does U+3000 change size in proportional fonts
florian: would it be reliable and would it be a representative?
atsushi: including Hiragana, Katakanta, and punctuation marks
… in jlreq meetings, people mentioned that there are three kind of proportional fonts in Japan
… one fills the embox
… the other two doesn't fill the embox
… IIRC U+3000 is set to the same width of Hiragana/Katakana and the width could change in proportional fonts
florian: maybe we should look at a sample of actual fonts and see what that does
<atsushi> cf. https://
florian: possibly an alternative is to use water, if there is not water, before falling back to the next font, look at U+3000
r12a: is the ic unit actually useful if you have proportional fonts?
florian: as an approximate one, yes
… the same way as the ch unit
… I don't know how to resolve this