Fix WPT test position-sticky-writing-modes.html to use an even font size, so that it's not inadvertently testing rounding behavior for fractional central baseline alignemnt
Categories
(Core :: Layout: Text and Fonts, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox110 | --- | fixed |
People
(Reporter: dholbert, Assigned: dholbert, NeedInfo)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
Attachments
(1 file)
Spinning this off from bug 1808788.
We fail WPT test https://wpt.fyi/results/css/css-position/sticky/position-sticky-writing-modes.html due to what I think is a faulty assumption in the test.
It uses the Ahem font for pixel-perfection, but it uses an odd font size (25px) with a vertical writing mode which makes us use the central baseline; and so we end up being forced to align on a fractional central-baseline position. We happen to round up (from 25/2=12.5px to 13px) when computing this alignment position, which ends up making us fail the test due to us having the Ahem characters shifted by 1px with respect to what the text is expecting.
Our behavior here seems reasonable (to the extent it's not, that's tracked in bug 1808788), and the test isn't actually intending to test this central-baseline rounding behavior anyway, so let's adjust the test to use an even font-size so that it's not relying on that.
|
Assignee | |
Comment 1•2 years ago
|
||
Before this patch, this test was using Ahem text with a 25px font-size and a
vertical writing mode. The vertical writing-mode causes the text to be
baseline-aligned using a central baseline, which ends up being at a
half-pixel position, since our font-size is odd. Specifically: the central
baseline is 25px/2 = 12.5px inwards from the edge of the glyph.
The UA may choose to round this fractional central baseline to a whole pixel
value when sizing/placing content, which in turn casues this test to fail with
content being 1px away from where the test expects it to be.
This patch addresses this issue by making the test use an even number as the
font-size (30px), which produces a nice whole-number pixel value for the
central basleine. This avoids creating a depending on the UA's choice of
rounding behavior.
This makes the test pass in Firefox, and I believe it continues to pass in
other browsers where it was already passing.
Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/940a9c333433 Use an even font-size in WPT position-sticky-writing-modes.html, so that it's not laying out text with a fractional central baseline. r=jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/37816 for changes under testing/web-platform/tests
|
||
Comment 4•2 years ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
|
|
Assignee | |
Comment 6•2 years ago
|
||
Setting ni=me as a reminder to update the WPT docs to not recommend 25px Ahem anymore -- specifically this line:
https://github.com/web-platform-tests/wpt/blame/fe30ab22c3088be330f87cb77ce5d584e6823e21/docs/writing-tests/ahem.md#L52
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 7•1 year ago
|
||
We also should keep in mind that if the line box height is an odd number, tests could fail due to fractional pixel. Eg
font-family: Ahem;
font-size: 30px;
line-height: 1.5;
|
|
Assignee | |
Comment 8•1 year ago
|
||
Yup, good point. Fortunately, that's already addressed in the guidelines at https://web-platform-tests.org/writing-tests/ahem.html?highlight=line%20height :
An explicit (i.e., not
normal) line-height should also always be used, with the difference between the computed line-height and font-size being divisible by 2. In the common case, having the same value for both is desirable.
[...]
div {
font: 25px/1 Ahem;
}
(/1 is the simple way to "[have] the same value for both" as suggested there.)
I still need to post a pull request to update the WPT docs, per comment 6 -- I'll be sure to avoid breaking that line-height recommendation.
Description
•