1437218 - <div><span> shrinkwrapping-bsize calculations are inconsistent in vertical vs. horizontal writing mode

Status: NEW

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:
 1. Load attached testcase.

EXPECTED RESULTS:
No red (or very little red, perhaps).
Or, at least: consistent behavior between the horizontal & vertical text.

ACTUAL RESULTS:
I see a thick (2px?) line of red to the left of the vertical text, and a thin (1px?) line of red to its right.



COMPARISON TO OTHER BROWSERS:
 - Edge 16 shows no red at all, regardless of zoom level. So they give "Expected results".
 - Chrome shows a thin red line on the "logical under" side of *both* runs of text (horizontal and vertical).  If I zoom in quite a lot, they show a thin red line on the "logical over" side as well.  So they give the looser "consistent behavior" version of my expected results.
 - Firefox Nightly gives "actual results" (considerably more red on the vertical-text example).

NOTES:
The red here is from the background of an intrinsically-sized div, which is (mostly) covered up by the white background on the <span> that holds the text.  The div is intrinsically sized to shrinkwrap the <span>, so I'd expect that none of its red should actually show (except maybe a teensy bit from rounding issues perhaps).

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase in linux Nightly

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase with 300% full-page-zoom in Linux nightly

If I bump up full-page-zoom all the way, then I get a subtle red line on one side of the horizontal text, but still much wider lines on the vertical text.

Specifically, at 300% zoomlevel (shown in this screenshot):
 - I see a line above the horizontal text that is 1px thick.
vs.:
 - I see a line to the left of the vertical text that is 5px thick.
 - I see a line to the right of the vertical text that is 4px thick.

The 1px-thick line is believable as a rounding error, but the other ones seem more suspicious....  jfkthame, do you know what might be going on here?

Comment 3

[Jonathan Kew [:jfkthame]]

Interesting... I notice (on macOS) that the results vary significantly depending on the font I'm using. With the default serif font (Times), I get just a single-pixel red line (at hi-dpi, so 0.5px) at a couple of zoom levels, nothing at all at others. But applying font-family:Arial to the testcase, I can get much thicker lines.

While a minor factor here is probably rounding (which could explain the odd single-device-pixel discrepancy here and there), I think the main issue must be related to line-height calculations. For some reason, the block-size of the vertical <span> is not taking account of line-height in the expected way.

It seems that the vertical <span> just gets a block-size of 1em, while the horizontal one gets a block-size equal to the "normal" line-height of the font being used. And the latter is the size that is used (in either writing mode) as the shrink-wrap size of the surrounding <div>. So how much red you see depends on the difference between the em size and the font's "normal" line-height.

One thing that may help to visualize what's going on is to add padding:1px to the <div>, so that the expected result is that we'll see a 1px red line all around the outside of the text. And then try varying the line-height to see the effect on the surrounding <div>, and the (lack of) effect on the block-size of the inner <span>.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Extended testcase showing effect of line-height

Comment 5

[Jonathan Kew [:jfkthame]]

Actually, the assumption that the shrink-wrap <div> will exactly fit the <span> may break down even in purely horizontal cases, if the text in the <span> ends up using fonts that have different metrics from the first available font in font-family.

For an example that's likely to show this, we can throw some CJK characters in to the content, while font-family is set to a simple Latin font, so fallback will kick in.

Also, line-height metrics with vertical writing-mode may well differ from those used in horizontal mode, because (by default) vertical writing mode works with a centered baseline (appropriate to CJK content). Applying text-orientation:sideways-right to the vertical element should, I think, be expected to give a result that matches the horizontal one (with 90° rotation) -- though it looks like in some cases, depending on the fonts involved, we don't handle this well either.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: Additional testcase that includes Chinese characters

Comment 7

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P3 ]