1513904 - <ruby> text rendered outside of bounding box

Status: RESOLVED INVALID

(Core :: Layout: Ruby, defect, P3)

Description

[Chris Barth]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce:

I used the following code:

<div style="background-color: lightblue;"><ruby>研读版<rt>Yándúbǎn</rt></ruby></div>




Actual results:

The text is rendered outside the containing <div>.


Expected results:

The size of the <div> should expand to contain the text rendered.

Comment 1

[Matthias Versen [:Matti]]

Please attach a full testcase using the "attach file" link in this report.

Comment 2

[Chris Barth]

Attachment: Chrome Ruby Appearance.png

Comment 3

[Chris Barth]

Attachment: Firefox Ruby Appearance.png

Comment 4

[Chris Barth]

Attachment: Ruby Container Sample.html

Comment 5

[Chris Barth]

I've uploaded an HTML file that can be used to reproduce this problem. I've also updated two images: 1) the incorrect rendering of Firefox, and 2) the correct rendering of Chrome.

Comment 6

[Paul_B]

Hello Chris,

Thank you for taking the time to report this issue. 
I managed to reproduce the reproduce the rendering issue mentioned above on Mac OS X, on all the latest Firefox versions (Release - 64.0/20181206201918; DevEdition - 65.0b4/20181211223337 and Nightly - 66.0a1/20181217000148). 

I did not notice the same issue reproducing on Windows 10, Windows 7 or Ubuntu 18.04 on any of the Firefox Versions.

Comment 7

[Jonathan Watt [:jwatt]]

Tentatively setting to P3.

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

I think this is the expected behavior per spec, specifically 3.5 Line Spacing[1] of CSS Ruby. The spec encourages authors to add sufficient line height and padding to accommodate ruby, rather than relying on browser to derive that.

There might be some better behavior we could provide. The existing of multi-level ruby and double-sided ruby may make the situation a bit more complicated, but probably still manageable.

I would suggest that the right place to discuss this would be in CSS WG. I think there were some discussions about that, but I cannot recall the details, while people there may have some insight on what we can do and what constraints we may have. You can file an issue there[2] to start the discussion.


[1] https://drafts.csswg.org/css-ruby-1/#line-height
[2] https://github.com/w3c/csswg-drafts/issues

Comment 9

[Chris Barth]

The problem comes in when different browsers expand the parent container in different ways. It seems to me that there are only two correct ways to do this, either the parent container doesn't get larger at all when there is ruby text, or it gets larger to fully enclose its contents. Currently, Firefox increases the size of the parent container a little, but not enough; how is one suppose to style around that?

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

If you provide a large enough line-height, the parent container wouldn't increase the size. It is only a "fixup"-ish stuff when line-height is not enough for ruby, as described in the spec.

Comment 11

[Chris Barth]

As much as I disagree with the statement that the container shouldn't expand to hold the contents, I see that there are others who agree with me:

"More control over how ruby affects alignment and line layout will be part of the CSS Line Layout Module Level 3. Note, it is currently in the process of being rewritten; the current drafts should not be relied upon."

In any case, it seems that this matter can be closed pending the results of the new CSS Line Layout Module Level 3 specification. I'll have to follow up with the csswg to share some challenges I've run into. Really, if content is expected to overflow its container by an un-determined amount, which can very by browser, it is impossible to correctly do many things with that block for example, vertically center it. All methods for doing this, including flex, require that there be a relation of the visual elements being centered to the box they are contained in. Arbitrarily increasing the size of the bounding box is not cross-browser compatible (though now that there are basically only two browser layout engines remaining: Firefox and Webkit/Chromium, this is less of a problem then it used to be).

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

Arbitrarily increasing the size of the bounding box is not cross-browser compatible (though now that there are basically only two browser layout engines remaining: Firefox and Webkit/Chromium, this is less of a problem then it used to be).

I'm not sure I have made it clear enough. There are two ways to achieve fully compatible:

• provide enough room for the annotation by yourself, which usually means line-height: 1.5 or larger and a padding of 0.5em, in which case, no browser would expand the line box, and thus the bounding box of the container
• provide no room for the annotation, which usually means line-height: 1 without any padding, in which case, browsers would fully expand the line box to fit the annotation, and thus the bounding box of the container

The only thing that is not compatible between browsers is that WebKit and Blink always try to expand the line box when any side of the line box is not enough, while Gecko only does so when the total line box is not enough. The latter is what described in the latest spec. It is not "arbitrary". It looks "arbitrary" only when you are not using it in the expected way.

Comment 13

[Xidorn Quan [:xidorn] UTC+10]

WebKit and Blink also tries to take start padding into account for the line box of the first line, which Gecko doesn't (since the spec doesn't say so).

Also, I would expect Blink to move to a modal more similar to Gecko's behavior, since the spec was co-authored by a core developer of Chromium layout team, and he has expressed interest to go that way in Blink. The timeline for them is unclear, though, because of low priority.

Comment 14

[Xidorn Quan [:xidorn] UTC+10]

Given this is expected behavior per spec, and there are ways to achieve compatibility, I think I'm going to close this as INVALID.

And if you have concerns for the algorithm described in the spec, you are welcome to file issue to CSS working group: https://github.com/w3c/csswg-drafts/issues/new

Comment 15

[Chris Barth]

I'm not proposing that this be re-opened, but I wanted to acknowledge your comments about how line-height is supposed to factor in to positioning. The sample I've attached shows that the behavior is very different for <ruby> text and normal text, which is a problem to start with because the same styling can't be used across the board; one has to know if the children contain ruby text before styling on the parent can be done, which is not possible with CSS, so that forces styling with JavaScript.

Additionally, you'll note in the sample that the line-height CSS property has very little effect on the result, and is quite unreliable to getting things to behave correctly. In order to get things to work correctly, one has to experiment with fractional values of line-height, which it tedious, but also fundamentally broken as a font stack may specify multiple fonts that are slightly different and not all available on every machine. If you run this sample on Firefox, Chrome, and Edge, you'll note that they all would require different fractional values of line-height, so that means applying CSS on a per-browser basis.

Finally, I've included samples that show that this is never a problem for single runs of text.

Also included in this sample are buttons to change the font size so one can see additional practical implications of this problem and again how they don't affect single normal lines of text. When dealing with ruby text, the inclusion of a feature to change the size of the text, or just the <rt> run individually, would be a desirable feature. In any case, CSS to change the font size on specific elements would need more individual tweaking per-browser, and with foreknowledge if that container will have <ruby>, so specific styles can be applied.

Comment 16

[Chris Barth]

Attachment: Ruby Sample.html

This more completely demonstrates the ramifications of the parent not containing the children.