1837692 - sub-pixel -webkit-text-stroke-width computation regressed in 115

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Dan Bjorge]

Revision 0f75cd1f132c (from bug 1834487) updated the computed value calculation for border-width-like properties to clamp to app units at computed value time. I agree that this change generally makes sense and matches the relevant bit of css-values-4 spec.

However, this change also impacted the -webkit-text-stroke-width property. Prior to the change, it was possible to specify sub-pixel text stroke widths, and the browser would successfully render a visible difference between a 2.1px and 2.9px text stroke width. As of this change, the browser now clamps text stroke widths similarly to the new behavior for border widths. You can see the difference in a test page (codepen example) along the lines of:

<div style="font-size: 50px; -webkit-text-stroke: 0.2px #aaf">0.2px stroke</div>
<div style="font-size: 50px; -webkit-text-stroke: 1px #aaf">1px stroke</div>

In Firefox 115+, the two cases render similarly; in Firefox 114 (or Chrome 114.0.5735.106), they are very visibly different.

As I understand it, because https://compat.spec.whatwg.org/#the-webkit-text-stroke-width doesn't specify explicitly that it should snap its length as a border width, the specific rounding behavior is implementation-defined, and it's not necessarily wrong for Firefox to choose to snap text stroke widths similarly to border widths.

However, in practice, I note that a substantial proportion of actual usage of this property does use subpixel values today (per a GitHub-wide search for webkit-text-stroke-width); this change is likely to break such cases. I wanted to file this issue to:

1. Double check whether whether or not this impact of the change was intended
2. Suggest that if it is intended, it might be good to include a release note documenting the change
3. Make it easier for others to search for this specific symptom (it was a bit challenging to map from the symptom to the underlying change)

Comment 1

[Emilio Cobos Álvarez [:emilio]]

So this change was sort of intended in the sense that I noticed that the change in bug 1834487 affected this property.

However I think snapping text stroke like we do for border widths makes sense. Subpixel stroke widths look rather weird before my patch...

Jonathan, thoughts? I could easily undo the snapping here to restore the previous behavior if you think it's not worth it.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: screenshot comparing Firefox 114 (left) vs Nightly (right), macOS retina screen

I'm inclined to think we should not be snapping text stroke widths. The subtle gradations of stroke width on the left-hand side of this example should be available to authors.

So IMO this is a regression, and we should revert to the previous behavior.

Comment 3

[Jonathan Kew [:jfkthame]]

Also, neither Chrome nor Safari appear to be snapping the stroke width.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Sounds good.

Comment 5

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

Set release status flags based on info from the regressing bug 1834487

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1837692 - Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Introduce LineWidth (which doesn't snap) and let BorderSideWidth
wrap it and actually do the snapping.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9338636 [details]
Bug 1837692 - Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Codepen in comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial-ish change.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a42bbb543c30
Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Comment 9

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

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

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/351c7940a309
Fix rebase conflict with bug 1837664.

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/a42bbb543c30
https://hg.mozilla.org/mozilla-central/rev/351c7940a309

Comment 12

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

Upstream PR merged by moz-wptsync-bot

Comment 13

[Donal Meehan [:dmeehan]]

:emilio servo/components/style/properties/shorthands/border.mako.rs has merge conflicts with beta.
Caused by Bug 1837664 which is only in central

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1837692 - [beta] Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Introduce LineWidth (which doesn't snap) and let BorderSideWidth
wrap it and actually do the snapping.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9338907 [details]
Bug 1837692 - [beta] Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Beta/Release Uplift Approval Request

• User impact if declined: see above
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: see above
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Relatively simple patch.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 16

[Donal Meehan [:dmeehan]]

Comment on attachment 9338907 [details]
Bug 1837692 - [beta] Do not snap -webkit-text-stroke-width to dev pixels. r=jfkthame

Approved for 115.0b5.

Comment 17

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b774c30788f0

Comment 18

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using an affected Nightly build (2023-06-09) with the test cases from comment 0.

The issue is verified as fixed on the latest builds, Beta 115.0b5 and Nightly 116.0a1 across platforms, Win 11 x64, macOS 11 and Ubuntu 20.04 x64.