1837533 - Pass the css/css-fonts/size-adjust.tentative.html WPT like Chrome and Safari now do

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Thomas Wisniewski [:twisniewski]]

Safari 17 will now support @font-face size-adjust, leaving Firefox as the only browser not passing the WPT: https://wpt.fyi/results/css/css-fonts/size-adjust.tentative.html?label=master&label=experimental&aligned

We should look into that before it potentially causes webcompat issues.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:TYLin, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Hi Jonathan, do you know if there is an easy fix to pass the test?

I'm setting S3 to get this off the triage queue. Please change it to other value if you feel otherwise. Thanks!

Comment 3

[Jonathan Kew [:jfkthame]]

It looks like the failure here is related to how line-height and/or baseline positioning behaves. The actual scaling of the font is working as expected, but we get slightly different vertical spacing in the test vs reference cases.

It'll need a bit of investigation to see whether this is really a gecko bug, or just a fragile test that doesn't take care to ensure consistent spacing (noting that the result of line-height:normal is not precisely specified, and is known to behave somewhat differently across browsers...)

Comment 4

[Daniel Holbert [:dholbert]]

Live links, for reference:
http://wpt.live/css/css-fonts/size-adjust.tentative.html
http://wpt.live/css/css-fonts/size-adjust-tentative-ref.html

It looks like this has to do with line-height:normal indeed, per comment 3, but in particular it has to do with how size-adjust impacts the size that normal resolves to.

I'll attach a reduced testcase or two that get to the heart of it.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a testcase showing three side-by-side blocks with different custom fonts. The second has a downscaling size-adjust, the third has an upscaling size-adjust.

We downscale very-slightly for the second one, whereas e.g. Chrome does not.

I think that's just a sign that our normal line-height for Ahem is larger than our normal line-height for our sans-serif font of the same size (so we have a little room to shrink the line-height, whereas Chrome does not).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 (Firefox on left, Chrome on right) showing the slightly-differing heights in Firefox from `size-adjust:50%` that results in the WPT test failure

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 in Firefox (left) vs Chrome (right)

Comment 9

[Daniel Holbert [:dholbert]]

There are two sections in the WPT test where we render the testcase with different layout from the reference case:

• Section (1): the 123xxx section (note, 123 renders as Ahem square-blocks) -- that section renders with a different height in the testcase vs. reference case. That reduces to testcase 1. (The first div is analogous to the WPT reference case, the second slightly-shorter div is analogous to the WPT testcase).

• Section (2): the final section with <span class="square">, where the test is comparing a shrinkwrapped 1em-tall inline element, in a div with the size-adjust:50% Ahem-backed font (testcase) vs. the equivalent setup without size-adjust (reference case). That reduces to testcase 2. (The bottom-left div is analogous to the reference case, and the bottom-center div is analogous to the testcase.) Interestingly, in testcase 2, Chrome agrees with us on the sizing/positioning with vertical-align:baseline (top left & top center).

Anyway: as far as I can tell, section (1) is has an unstated/unjustified expectation that Ahem's line-height:normal must be no-greater-than the same-font-size sans-serif font's line-height. (If that holds, then there's no room for the size-adjust to reduce the line height there, because the sans-serif text is "propping it up".)

And section (2) has an unstated/unjustified expectation that Ahem's ``line-height:normalmust be exactly 1em. (If that holds, then the tallest<span class="square">` child will be flush with the top of the block there, in both the testcase and the reference case. But: in browsers where the `normal` line-height is taller than 1em, the testcase may have that line being somewhat taller in the reference case vs. the testcase, with the square being bottom-aligned in whatever height the line ends up.)

I'm not yet sure what the best workaround is for (1); working on that...
But we can fix (2) by specifying line-height:1 on the container in the reference case.

Comment 10

[Daniel Holbert [:dholbert]]

Reasonable workaround for (1) seems to be to just set an explicit height on the target wrapper.

(I also tried setting line-height:1 there, but that has side effects that end up requiring more work to avoid. Really, the only rendering difference in that section is the height of that wrapper-box, which influences later content. That height is influenced by how size-adjust might impact the resolved line-height:normal, depending on the default normal value. So, we might as well just break that chain of influence by locking in that height directly.)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: Bug 1837533: Fix WPT size-adjust.tentative.html to reduce unintended dependencies on 'line-height:normal' resolution behavior. r?jfkthame

As discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1837533#c9 , this
test had two sections that were making extra assumptions about what the default
line-height:normal value resolves to. This commit avoids those assumptions by
breaking the chain of influence between the resolved 'line-height' value and
the actual rendering in these two sections -- in one case by setting an
explicit 'height', and in the other case by setting an explicit 'line-height'.

Comment 12

[Daniel Holbert [:dholbert]]

Looks like we still have a ~2px vertical-positioning difference on macOS, independent of the fixups that I'm landing here:
https://treeherder.mozilla.org/jobs?repo=try&revision=66114305acef75aee7c9f909bbc361e4e229decf&searchStr=macos&selectedTaskRun=P1wKeknSSfGyWlyzmb9RZQ.0

I'll annotate this test as expected-fail on macOS for now.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7ff55e59948
Fix WPT size-adjust.tentative.html to reduce unintended dependencies on 'line-height:normal' resolution behavior. r=jfkthame

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42670 for changes under testing/web-platform/tests

Comment 15

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/e7ff55e59948

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot