Re: [csswg-drafts] [css-ruby] Overhanging and auto-hiding (#1908)

Interesting cases, probably in the spirit of @upsuper 's original comment, would be words like `<ruby><rb>働<rb>き<rb>手<rt>はたら<rt>き<rt>て</ruby>` or `<ruby><rb>考<rb>え<rb>方<rt>かんが<rt>え<rt>かた</ruby>`. They are kind of like like 振り仮名 in the sense of having an unanotated base in the middle, but with 3 annotation characters for the first base, there's a question of overhang.

<img width="139" alt="Screen Shot 2021-02-05 at 15 22 40 2" src="https://user-images.githubusercontent.com/113268/106997364-1ba64880-67c6-11eb-8b69-f01274aad9c3.png"> <img width="128" alt="Screen Shot 2021-02-05 at 15 22 40" src="https://user-images.githubusercontent.com/113268/106997368-1c3edf00-67c6-11eb-8f55-bbde76e5f285.png">

The `ruby-merge:separate` rendering currently requires adding a gap between the first and second bases in both those examples, to make sure the last character of the first annotation does not overhang the second base, but maybe we could allow that. However, if we do, we'd be at risk of running into the same kind of colliding annotations problem discussed in [Figure 137](https://www.w3.org/TR/jlreq/#fig2_3_29_2) of JLREQ, and would need the sort of solutions illustrated in [fig 138](https://www.w3.org/TR/jlreq/#fig2_3_29_3). Solving this properly is reasonably complicated, and factors in a lot of subjective opinions, so I don't think I really want to go into allowing one particular type of intra-ruby overhang, together with one particular mitigation strategy for the problematic cases.

Currently 'ruby-overhang: auto | none' only controls overhang of the ruby onto neighboring inlines. Maybe it could be expanded to control (possibly with the same value, possibly with a second one) whether intra-ruby overhang is allowable, leaving most of the details up to the UA, as we do for overhang onto neighboring inlines. I suppose this would have no effect under ruby-merge:auto, which already let internal overhang happen anyway. And it's not relevant for ruby-merge:merge either. The only difference would be for annotations with ruby-merge:separate.

I suppose the way I'd spec that is to say that if annotations where ruby-overhang-internal is auto are wider than the column they're in, the UA is allowed to overflow the ruby column, as long as that does not make them collide with a neighboring annotation on the same level. The UA should probably also not just stop at the point they'd touch, but keep a minumum (UA-defined) distance, and it would also be allowed to take other things into account (whether the neigboring base has any annotation, whether it's text is kanji or kana… anything it thinks is relevant). However, to keep ruby-merge:separate + overhang from becoming the same thing as ruby-merge: auto, it would not be allowed to change the alignement between the annotation and the base it is paired with.

Or something like that.

That said, while I think we could specify something like this, I am unconvinced it is worth it. We already have plenty of moving parts and a decently complicated model, and I'd rather we first got the basics down. So my preference would be to go on disallowing internal ruby overhang, at least for now. If we change our mind later, we can always add a second value to ruby-overhang, which defaults to none when omitted to explain the current behavior, but could be switched on.



-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1908#issuecomment-773821713 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 5 February 2021 06:24:31 UTC