1869187 - Ruby rt element is improperly cropped with line-height

Status: NEW

(Core :: Layout: Ruby, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-03-29)]

Attachment: ruby-line-height-cropped.htm

Attaching the minimal repro, only on Windows because of the font dependency.

Two things:

• Removing Arial from font-family solves the issue, although devtools says Meiryo is already selected. This somehow adds extra line-height than Chrome does. Doing this does not affect anything on Chrome.
• Setting line-height with lower value solves the issue, and higher value also solves the issue. This is especially suspicious as the behavior of line-height: 0px is super different from Chrome; Gecko crops nothing but Chrome crops the half of the rb element.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-03-29)]

Attachment: visual-difference.png

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I can also reproduce this issue on Ubuntu.

I would say this is an expected behavior based on CSS Ruby spec, and is an unfortunate result of an otherwise well-intended algorithm.

If you change the line-height value continuously from zero to large value, the content would move up, then after a point, move down. The turning point, or where the content is at highest position, is when line-height is the height of the rb box + that of the rt box.

The algorithm described in the spec is basically: if the total specified line-height is big enough to accommodate all levels of boxes, then it's untouched, otherwise a difference between line-height and the minimum value needed is added to the sides that need the space.

So when line-height is larger than or equal to the sum of the height of the boxes, then no extra space is added to the line, and line-height is as usual distributed equally on the two sides of the line. In this case where the container applies overflow: hidden, up to half of the ruby text box would be cropped.

I'm not sure what to do with this, as I think the algorithm is reasonable. While some further tweak of it may make it more resilience to this kind of issues, that could create other layout issues, and itself would also become much more complicated.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them) (OOO until 2025-03-29)]

I think the work item is to investigate why the difference between ours and Chrome/Safari exists, as I can confirm that Safari doesn't have this issue either.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

The difference exists because Chrome and Safari don't implement the behavior in the spec. They have a more magic behavior that, IIRC, the editors of the spec intentionally didn't want to adopt.

Comment 5

[Thomas Wisniewski [:twisniewski]]

Removing the webcompat link, and moving it to our webcompat knowledge base for this issue, bug 1891114.