Intent to Ship: CSS font-size-adjust with the two-value syntax

478 views
Skip to first unread message

ChangSeok Oh

unread,
May 16, 2024, 10:02:57 AMMay 16
to blink-dev
Contact emails
None

Specification
https://www.w3.org/TR/css-fonts-5/#font-size-adjust-prop

Summary

The font-size-adjust CSS property enhances readability consistency by adjusting font size based on lowercase letter height rather than uppercase. Additionally, the newly introduced two-value syntax for font-size-adjust in the font module level 5 enables web designers to specify a font metric for size adjustment. This feature is one of focus areas for Interop 2024.


Blink component
Blink>CSS, Blink>Fonts

TAG review
None

TAG review status
Not applicable

Risks
Interoperability and Compatibility

Gecko and WebKit have shipped this feature, and there is no major interoperability risk. However, certain aspects are still being discussed regarding interoperability concerns. [1, 2].

[1] https://github.com/w3c/csswg-drafts/issues/6384 [2] https://github.com/w3c/csswg-drafts/issues/10292


Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1711479)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=254191)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None


Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes. Windows experiences a minor sub-pixel mismatching issue in one wpt test, but it doesn't affect usability.

Is this feature fully tested by web-platform-tests?
Yes

Flag name on chrome://flags
enable-experimental-web-platform-features

Finch feature name
CSSFontSizeAdjust

Requires code in //chrome?
False

Tracking bug

Measurement
- https://caniuse.com/font-size-adjust

Availability expectation
Both the Gecko and WebKit communities have implemented this feature, and corresponding tests are already included in the Web Platform Tests (WPT).

Adoption expectation
Firefox and WebKit variant browsers have embraced this feature.

Adoption plan
Blink is shipping this feature.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None


Sample links
https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust

Estimated milestones
Shipping on desktop
127
Shipping on Android
127
Shipping on WebView
127

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).


Some concerns related to interoperability are still under discussion.

- https://github.com/w3c/csswg-drafts/issues/10292

Link to entry on the Chrome Platform Status

Links to previous Intent discussions

Best,

Vladimir Levin

unread,
May 16, 2024, 11:01:46 AMMay 16
to ChangSeok Oh, blink-dev
Do you mind starting the various reviews (including API Owners) in the chromestatus entry?:

chips.png

Thanks!



Links to previous Intent discussions

Best,

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b34b218a-28c4-44e0-9451-3a2fc0949ab3n%40chromium.org.

Philip Jägenstedt

unread,
May 21, 2024, 8:43:38 AMMay 21
to Vladimir Levin, ChangSeok Oh, blink-dev
Hi ChangSeok,

Thank you for working on this, it's great to see both more powerful typography control, and progress on Interop 2024.

Can you say something about the remaining failures in WPT? font-size-adjust-012.html font-size-adjust-013.html both look like minor differences, but it seems like it only happens on Linux (Chrome) and not Windows (Edge)?

There are also 3 failing subtests in font-size-adjust-computed.html, does that depend on resolving one of the spec issues? Or can we match what Firefox and Safari do and pass the tests without waiting for spec changes?

Best regards,
Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NOwQS9mwe7rrShcyapRmWTFh6%3DUTo9%2BGE%2B2E525TrpEA%40mail.gmail.com.

Dominik Röttsches

unread,
May 21, 2024, 9:13:58 AMMay 21
to Philip Jägenstedt, Vladimir Levin, ChangSeok Oh, blink-dev
Big thanks ChangSeok for implementing this and pushing for this feature.

I can say a few things about the open issues
 

font-size-adjust relies on a font metric reference point, for example, the x-height, cap-height, etc. in order to scale font sizes to match on a scaled metric.
Strictly speaking in the OpenType font spec, some metrics that are spec'ed for font-size-adjust are optional in the font file. They might not exist in the font file.
The discussion in this issue revolves around what to do when the metric does not exist: There are mainly two alternatives:
a) don't adjust anything, b) adjust to a heuristic that tries to approximate the missing value. 

From an interop point of view: a) is interoperable, b) is not interoperable without spec changes in the CSS values spec to tighten the heuristics. 
For Interop 2024, I think we can and should only test and consider the happy path, in which the font has the metrics. 

The missing metrics situation can be considered a somewhat rare edge case.
 

This discussion is about the computed style of font-size-adjust and whether that should "leak" actual values that come from the font files. If I am not mistaken, FF and Safari are currently aligned on doing that and making the computed style show values from the font files, in order to inherit a meaningful numerical value in the cascade. There are arguments for why this is the right approach from a functionality point of view. Whether it's the right approach from a CSS inheritance / logical point of view is perhaps the question. I am not sure about WPT test coverage at the moment (it's likely small), but for the time being I believe we can align with Safari and FF. ChangSeok, do you agree?

Dominik


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdEOTMqLunu0zpsqqrS2XifPx9D%2BaXEwHS04gHVMRPKGw%40mail.gmail.com.

ChangSeok Oh

unread,
May 22, 2024, 4:00:34 PMMay 22
to Philip Jägenstedt, blink-dev
Hi Philip,

I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show minor deviations from expected results. The exact issue with the WPT Linux machine is unclear since these tests can be affected by various font rendering configuration and environment (e.g., hinting, sub-pixel rendering, fonts installed, font rendering libraries, etc.). My Linux machine and the Linux try bots pass these tests. I think syncing the WPT Linux machine's font setup with our Linux trybot's setup could help.

The only actual failure I know of is the ic-height test of font-size-adjust-computed.html. This is due to unclear fallback behavior in the font spec when the necessary font metrics are missing, which is still under discussion by CSSWG, as I noted. Depending on the resolution, some test results can change later. I will follow up on this standardization effort.

Best,

--
ChangSeok

ChangSeok Oh

unread,
May 22, 2024, 4:00:37 PMMay 22
to Vladimir Levin, blink-dev
Hi Vladimir,

I requested the reviews in the chromestatus. Thanks.

--
ChangSeok

ChangSeok Oh

unread,
May 22, 2024, 4:05:07 PMMay 22
to Dominik Röttsches, blink-dev
Hi Dominik,

Thanks for your add-up! And Yes, we can align with other browsers for the time being.

--
ChangSeok

Philip Jägenstedt

unread,
May 23, 2024, 12:05:55 PMMay 23
to ChangSeok Oh, blink-dev
On Wed, May 22, 2024 at 10:00 PM ChangSeok Oh <chan...@chromium.org> wrote:
Hi Philip,

I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show minor deviations from expected results. The exact issue with the WPT Linux machine is unclear since these tests can be affected by various font rendering configuration and environment (e.g., hinting, sub-pixel rendering, fonts installed, font rendering libraries, etc.). My Linux machine and the Linux try bots pass these tests. I think syncing the WPT Linux machine's font setup with our Linux trybot's setup could help.

I see. If it's passing in Chromium's setup then we can be pretty confident it's just a configuration issue. That will affect the Interop 2024 scores, but that shouldn't block this intent.

Philip Jägenstedt

unread,
May 23, 2024, 12:07:15 PMMay 23
to ChangSeok Oh, Dominik Röttsches, blink-dev
Thank you for looking into the test failures, ChangSeok!

LGTM1 to align with Firefox and Safari on the remaining failures (except the reftests with minor pixel differences) and shipping!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CC3F19D7-8FDE-402E-9B46-F17C0F1D9D26%40chromium.org.

Mike Taylor

unread,
May 23, 2024, 1:02:36 PMMay 23
to Philip Jägenstedt, ChangSeok Oh, Dominik Röttsches, blink-dev

LGTM2

Vladimir Levin

unread,
May 23, 2024, 1:19:41 PMMay 23
to ChangSeok Oh, Philip Jägenstedt, blink-dev
On Wed, May 22, 2024 at 4:00 PM ChangSeok Oh <chan...@chromium.org> wrote:
Hi Philip,

I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show minor deviations from expected results. The exact issue with the WPT Linux machine is unclear since these tests can be affected by various font rendering configuration and environment (e.g., hinting, sub-pixel rendering, fonts installed, font rendering libraries, etc.). My Linux machine and the Linux try bots pass these tests. I think syncing the WPT Linux machine's font setup with our Linux trybot's setup could help.

One thing you can try is running this test from wpt.live on your local build. In the past, I've used that to reproduce failures that would otherwise pass on the bots. I think this is worthwhile to pursue but I agree that it shouldn't block the intent.

LGTM3, thanks!
 

ChangSeok Oh

unread,
May 29, 2024, 1:31:33 PMMay 29
to Vladimir Levin, Philip Jägenstedt, blink-dev

> On May 23, 2024, at 10:19 AM, Vladimir Levin <vmp...@chromium.org> wrote:
>
>
>
> On Wed, May 22, 2024 at 4:00 PM ChangSeok Oh <chan...@chromium.org> wrote:
> Hi Philip,
>
> I noticed that font-size-adjust-012.html, font-size-adjust-013.html, and parts of font-size-adjust-computed.html (e.g., ch-width and ic-width) show minor deviations from expected results. The exact issue with the WPT Linux machine is unclear since these tests can be affected by various font rendering configuration and environment (e.g., hinting, sub-pixel rendering, fonts installed, font rendering libraries, etc.). My Linux machine and the Linux try bots pass these tests. I think syncing the WPT Linux machine's font setup with our Linux trybot's setup could help.
>
> One thing you can try is running this test from wpt.live on your local build. In the past, I've used that to reproduce failures that would otherwise pass on the bots.

This is a good idea worth trying. When I casually tested it with an existing Chromium build on Linux, I encountered a technical issue with running WPT. I'll give it another shot later with a freshly updated build.

> I think this is worthwhile to pursue but I agree that it shouldn't block the intent.
>
> LGTM3, thanks!

Thanks for the LGTMs. By the way, the ChromeStatus page is still gray due to one missing approval. Could you check it and add your approval if you forgot it?
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Mq8AJwc6Nap86%2B%3DWXrT9a6cyptKa4Mr4D5KOJHkRPBGQ%40mail.gmail.com.


Jason Robbins

unread,
May 29, 2024, 7:53:27 PMMay 29
to blink-dev, chan...@chromium.org, vmp...@chromium.org, Philip Jägenstedt
Pro-tip for API Owners who want to get their L-G-T-M's detected via email: start your reply with the magic word.

ChromeStatus only looks for LGTMs in the first non-blank line of your message, which could be a whole paragraph since people usually don't break lines themselves in emails.   The reason for that is to avoid detecting one that is mentioned as part of a nuanced discussion, e.g., "You are missing these things... <br> ... <br>.... After you address them, I will be happy to LGTM."    Meta-example: I could use LTGM in this point in the discussion without accidentally approving the request myself because this is not the first non-blank line.

Also, since we are on the topic, ChromeStatus will not treat the phrases "not LGTM", "almost LGTM", "need LGTM", "want LGTM", or "missing LGTM" as an approval.  But, if you use some other negative term, it might slip past that rule and be counted as approval.  If that ever happens, you can always change your vote on chromestatus.com.

Thanks,
jason!


On Wednesday, May 29, 2024 at 10:31:33 AM UTC-7 chan...@chromium.org wrote:

Thanks for the LGTMs. By the way, the ChromeStatus page is still gray due to one missing approval. Could you check it and add your approval if you forgot it?

Thanks,
jason! 
Reply all
Reply to author
Forward
0 new messages