[css-ruby] Ruby offset

[xfq]

From a clreq meeting:

... in the current css-ruby draft, it seems that the distance between ruby text and base text cannot be adjusted

I think we need a property for setting the offset of ruby from its default position, because sometimes the default position doesn't look good enough.

[nigelmegitt]

TTWG may be interested in this - see w3c/ttml3#8 for part of the history: ruby offset was included in a WD of TTML2 but removed before CR, in part due to lack of CSS implementation. The removed spec text can be found at https://www.w3.org/TR/2017/WD-ttml2-20170630/#style-attribute-rubyOffset

CC @skynavga @cconcolato @palemieux

[macnmm]

If it were possible for the default position of the ruby to have ruby embox bottom touch the embox top of the base text, this feature request would be unnecessary. As it is now, it is difficult to control placement via Latin font metrics to get the correct effect.

[frivoal]

There is no dedicated ruby property, as offsetting ruby can already be done with margins (or paddings, or even borders):

https://jsbin.com/nunuqey/edit?html,css,output (view in Firefox, other browsers' ruby implementation are insufficient to show this).

By spec, the (groups of) annotations are supposed to be stacked immediately against the (groups of) bases, margin-box against margin-box, (which is why margin/border/padding on bases or annotations can be used as offsets).

That said, margin/border/padding are added to the content area, but the content area of inline boxes is currently not defined and is implementation dependent. That part of the box model is know to be weak (see the second note in css-inline section 3.3.1), and needs more work. Maybe some switches are needed to control what the content area of an inline is in general, maybe some are needed for ruby specifically, or maybe we just need to agree on what the default is. Either way, that's separate from the need for a ruby offset, which we do have in the form of margins (or paddings, or borders).

[css-meeting-bot]

The CSS Working Group just discussed ruby offset, and agreed to the following:

• RESOLVED: No change, because mbp already handle this case sufficiently.

The full IRC log of that discussion

<TabAtkins> Topic: ruby offset
<Rossen_> github: https://github.com//issues/4932
<TabAtkins> florian: REquest for something that allow syou to move ruby annotation away from base text
<TabAtkins> florian: Already in the spec, turns out
<TabAtkins> florian: Box model isnt' fully detailed, but
<TabAtkins> florian: It *does* say that ruby bases and annos can get mbp, and their margin boxes get positioned
<TabAtkins> florian: So if you want to push ruby annos away from base text, you can use mbp
<TabAtkins> florian: So I hope we can conclude this is enough
<TabAtkins> florian: And conclude that this isn't accidental, and we should keep it working as we work thru other issues
<fremy> lgtm I guess
<TabAtkins> florian: Also, since it's been 6years, do we need to re-explain ruby?
<TabAtkins> [florian gives a quick rundown of what ruby is]
<fantasai> picture - http://fantasai.inkedblade.net/weblog/2011/ruby/ruby-intro.png
<TabAtkins> florian: so if you want to move the anno away from teh base, can put mbp on either and they'll move apart
<TabAtkins> florian: Given we can do that, I don't think we need a dedicate dproeprty to move them apart some other way
<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.
<TabAtkins> florian: If people agree, we'll resolve to close this issue with no action, bc we already have the appropraite proeprty
<Rossen_> q?
<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
<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
<xidorn> q+
<TabAtkins> florian: Mostly you have one layer of ruby, and it's mostly positioned according to language stadnards.
<xidorn> q-
<fantasai> abbr { display: ruby; } abbr::after { content: attr(title); display: ruby-text; font-size: 50%; }
<TabAtkins> florian: RArely, you can have multiple ruby layers, and one migth be above or below
<fremy> (but they would have different margins if they represent different levels, so I think it's fine)
<TabAtkins> florian: Also in subtitles, the top line's ruby is usually on top, the bottom line's usually on bottom.
<TabAtkins> myles: Seems like we should design based on the supposition people *might* ask for it
<TabAtkins> AmeliaBR: Any practical example of... do margins work for this in the impls we have?
<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.
<TabAtkins> AmeliaBR: So sound sreasonable to WONTFIX
<TabAtkins> fantasai: Sounds already fixed to me.
<TabAtkins> stantonm: I'm not against this, but am concerned by implications.
<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.
<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.
<TabAtkins> florian: I think there's bascially two usecases
<TabAtkins> florian: ONe is what you just said, fixing alignment the browser got wrong
<TabAtkins> florian: The other is, roughlys peaking, a11y-driven
<TabAtkins> florian: People can get too confused if the anno is too close to the base. A type of dyslexia.
<myles> q+
<TabAtkins> florian: For that case what we have here works fine.
<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
<TabAtkins> stantonm: Not sure. At least for us we use the ascent metric, and it looks pretty bad in common fonts, including NotoCJK
<TabAtkins> fantasai: This is a general problem witht he inline model that we've talked about solving with leading-trim
<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
<TabAtkins> myles: A little something extra, about styling different based on fallback font.
<TabAtkins> myles: There's an open issue about this, and it's a more general problem than just ruby
<TabAtkins> myles: Authors often want line-height to change based on fallback
<faceless2_> https://github.com//issues/4792
<TabAtkins> myles: So we shouldn't try to fix that case just for ruby; should do a general solution
<TabAtkins> myles: Another avenue being discussed is allowing CSS to override the data in the font
<tantek> I tend to agree with myles
<Rossen_> ack e
<Rossen_> ack f
<Rossen_> ack m
<myles> q-
<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
<TabAtkins> florian: That's why we have 9 issues today, not just one ^_^
<TabAtkins> Rossen_: So any objection to resolving no change?
<TabAtkins> RESOLVED: No change, because mbp already handle this case sufficiently.

[frivoal]

@xfq About to close this issue, please confirm if the resolution is satisfactory.

[xfq]

Looks good to me. Thank you!