You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not clear how text decorations should be rendered on ruby elements, or more specifically, what should happen on sides of short base text with long annotation?
For example, if we have content like:
<ruby>base 1<rt>a very very very long annotation</rt>base 2<rt>another very
very very long annotation</rt></ruby>
then we specify "text-decoration: underline" to <ruby> or some of its inline ancestors. What should happen? Currently, WebKit and Blink and Trident won't draw the underline in the gap between the bases, and between text preceding/following and the ruby, while Gecko will draw lines in those places. More precisely, Gecko currently extends the decoration lines to the boundary of each box, other impls don't do that.
It seems to me that our (Gecko) impl makes more sense if the ruby is part of a sentence, while other impls make more sense when ruby is put alone as a single word.
This problem becomes more complicated when considering the different values of ruby-align. I guess users of "center" and "start" probably don't want to extend the lines to the boundary of boxes.
I think underline text decorations should always extend over annotations for ruby-align: center. I ran into this issue in Firefox 50 recently where a link was split into two to three components because of the "ruby overhang skip" effect and ultimately decided to hide all annotations nested within annotations because the presentation was so ugly.
I can imagine desirability for ruby underlines not extending over a final overhang for ruby-align: start or empty bases at either end of a ruby sequence, but I don't think it would be terrible for underlines to extend over those annotations either.
There's an open question around the inline-axis application of text-decoration on ruby, see the following posts from www-style:
@upsuper's issue https://lists.w3.org/Archives/Public/www-style/2015Feb/0096.html
@patrickdark's response https://lists.w3.org/Archives/Public/www-style/2016Dec/0106.html
The text was updated successfully, but these errors were encountered: