- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 21:18:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `ruby offset`, and agreed to the following:
* `RESOLVED: No change, because mbp already handle this case sufficiently.`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> Topic: ruby offset<br>
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4932<br>
<TabAtkins> florian: REquest for something that allow syou to move ruby annotation away from base text<br>
<TabAtkins> florian: Already in the spec, turns out<br>
<TabAtkins> florian: Box model isnt' fully detailed, but<br>
<TabAtkins> florian: It *does* say that ruby bases and annos can get mbp, and their margin boxes get positioned<br>
<TabAtkins> florian: So if you want to push ruby annos away from base text, you can use mbp<br>
<TabAtkins> florian: So I hope we can conclude this is enough<br>
<TabAtkins> florian: And conclude that this isn't accidental, and we should keep it working as we work thru other issues<br>
<fremy> lgtm I guess<br>
<TabAtkins> florian: Also, since it's been 6years, do we need to re-explain ruby?<br>
<TabAtkins> [florian gives a quick rundown of what ruby is]<br>
<fantasai> picture - http://fantasai.inkedblade.net/weblog/2011/ruby/ruby-intro.png<br>
<TabAtkins> florian: so if you want to move the anno away from teh base, can put mbp on either and they'll move apart<br>
<TabAtkins> florian: Given we can do that, I don't think we need a dedicate dproeprty to move them apart some other way<br>
<jensimmons> I've also seen folks advocate for using Ruby to annotate emoji — to add a bit of additional information to the emoji. So it's not just for CJK.<br>
<TabAtkins> florian: If people agree, we'll resolve to close this issue with no action, bc we already have the appropraite proeprty<br>
<Rossen_> q?<br>
<TabAtkins> AmeliaBR: There's an option to have the anno above or below the base; I guess there's no logical property to say "offset away from the text" using margins<br>
<TabAtkins> AmeliaBR: Don't know enough about ruby to know if you'd likely be switching between top and bottom ruby in one doc, or if it's consistent<br>
<xidorn> q+<br>
<TabAtkins> florian: Mostly you have one layer of ruby, and it's mostly positioned according to language stadnards.<br>
<xidorn> q-<br>
<fantasai> abbr { display: ruby; } abbr::after { content: attr(title); display: ruby-text; font-size: 50%; }<br>
<TabAtkins> florian: RArely, you can have multiple ruby layers, and one migth be above or below<br>
<fremy> (but they would have different margins if they represent different levels, so I think it's fine)<br>
<TabAtkins> florian: Also in subtitles, the top line's ruby is usually on top, the bottom line's usually on bottom.<br>
<TabAtkins> myles: Seems like we should design based on the supposition people *might* ask for it<br>
<TabAtkins> AmeliaBR: Any practical example of... do margins work for this in the impls we have?<br>
<TabAtkins> florian: We have one impl; Firefox implements the spec. Other browsers have their own disconnected impls. But Firefox's impl does work with mbp.<br>
<TabAtkins> AmeliaBR: So sound sreasonable to WONTFIX<br>
<TabAtkins> fantasai: Sounds already fixed to me.<br>
<TabAtkins> stantonm: I'm not against this, but am concerned by implications.<br>
<TabAtkins> stantonm: People want this because the position where the UA displays the ruby above the text is derived form font metrics, and not always right.<br>
<TabAtkins> stantonm: So if an author is using margin to shift the anno, and the font falls back, it might not have the desired separation.<br>
<TabAtkins> florian: I think there's bascially two usecases<br>
<TabAtkins> florian: ONe is what you just said, fixing alignment the browser got wrong<br>
<TabAtkins> florian: The other is, roughlys peaking, a11y-driven<br>
<TabAtkins> florian: People can get too confused if the anno is too close to the base. A type of dyslexia.<br>
<myles> q+<br>
<TabAtkins> florian: For that case what we have here works fine.<br>
<TabAtkins> florian: For the case you're describing, guess it dpeends on whether people are fixing because impls are bad, or if even once bugs are fixed it'll still need patching<br>
<TabAtkins> stantonm: Not sure. At least for us we use the ascent metric, and it looks pretty bad in common fonts, including NotoCJK<br>
<TabAtkins> fantasai: This is a general problem witht he inline model that we've talked about solving with leading-trim<br>
<TabAtkins> fantasai: Recently resolved to apply it to inline boxes, and ruby annos are inlines; this'll let you control what ist he "top" of an inline box<br>
<TabAtkins> myles: A little something extra, about styling different based on fallback font.<br>
<TabAtkins> myles: There's an open issue about this, and it's a more general problem than just ruby<br>
<TabAtkins> myles: Authors often want line-height to change based on fallback<br>
<faceless2_> https://github.com/w3c/csswg-drafts/issues/4792<br>
<TabAtkins> myles: So we shouldn't try to fix that case just for ruby; should do a general solution<br>
<TabAtkins> myles: Another avenue being discussed is allowing CSS to override the data in the font<br>
<tantek> I tend to agree with myles<br>
<Rossen_> ack e<br>
<Rossen_> ack f<br>
<Rossen_> ack m<br>
<myles> q-<br>
<TabAtkins> dbaron: It's not clear to me how much the spec says about how mucht he ruby shoudl go; perhaps it should say more there<br>
<TabAtkins> florian: That's why we have 9 issues today, not just one ^_^<br>
<TabAtkins> Rossen_: So any objection to resolving no change?<br>
<TabAtkins> RESOLVED: No change, because mbp already handle this case sufficiently.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4932#issuecomment-622119003 using your GitHub account
Received on Thursday, 30 April 2020 21:18:32 UTC