Review Request: CSS Fonts src: descriptor syntax for client side font selection

[drott]

I'm requesting a TAG review of the extended format() and supports(<technology>) syntax of the src: descriptor of @font-face, see 4.3.1. Parsing the src descriptor of the CSS Fonts spec.

src: ... [ format(<font-format> [supports <font-technology>#]?)]?

The extended syntax serves as a means for the UA to select the most advanced font technology from a list of stated font sources, by traversing the list and selecting the first for which the UA provides support.

As Chrome would be the first browser to ship support for the supports(<font-technology>) I am requesting TAG review.

Because the specification also mandates the UA to drop unsupported entries from the list of sources specified in the @font-face src: line, this syntax can be used together with JavaScript accessing the CSSOM in order to detect which features are supported. This provides desired feature detection capabilities before the introduction of the COLRv1 font format.

Feature detection of font formats is already possible through canvas based methods, see more details in the additional security and privacy considerations below.

• Explainer: https://github.com/drott/format-supports-explainer
• Specification URL: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing
• Tests: I will contribute WPT tests on the path towards shipping in Chrome.
• Security and Privacy self-review²: https://drafts.csswg.org/css-fonts-4/#priv-sec - Additional considerations below.
• Primary contacts (and their relationship to the specification):
  • Dominik Röttsches, @drott, Google
  • CSS Fonts Spec editors
    • Chris Liley, @svgeesus, W3C
    • Myles Maxfield, @litherum, Apple
    • John Dagget, @nattokirai, Invited Expert at W3C
• Organization(s)/project(s) driving the specification: Multiple, introduced with the main intent of allowing selection of variable font resources in issue 633 in the CSS WG.
• Key pieces of existing multi-stakeholder review or discussion of this specification:
  • CSS WG Resolution for issue #633 initially adding format() and supports() syntax
  • CSS WG change in issue #6340 to clarify parsing rules for supports syntax
  • blink-dev intent to ship thread
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • https://crbug.com/1216460

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: ideally as soon as possible, as we'd like to have a way of COLRv1 font format feature detection available before shipping COLRv1
• The group where the work on this specification is currently being done: CSS WG
• Major unresolved issues with or opposition to this specification:
  • No major unresolved issues, TAG review requested mainly as we would be the first to ship in Chrome and considerations listed below.
• This work is being funded by: Google

Additional considerations

Additional privacy considerations

In addition to the security and privacy self-questionnaire of the CSS fonts spec:

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Font technology support can generally be detected using Canvas methods, compare https://pixelambacht.nl/chromacheck/ made by @RoelN. Exposing font technology support in this syntax would thus not expose fundamentally new information.

In the Blink-dev intent-to-ship @krgovind also asked, "...whether this mechanism could reveal anything more granular than the major version of the user agent. Is it possible for font technology support to evolve faster than major UA versions (e.g. via OS stack updates, or in minor UA versions)?"

I responded, that it depends on whether we look at a particular implementation or look at the spec conceptually:

Speaking for Chrome, changes in which font technologies are supported would usually coincide with a major version of the user agent, indeed, or switching a flag on when using a rollout via Chrome variations/flags. In Blink, we use a hybrid font stack that is composed of the system font stack's rasterising capabilities (DirectWrite, CoreText) combined with Skia +FreeType's rasterisation capabilities to fill in gaps in the system rasteriser. Using this stack, we can provide support for all the font formats we support (OpenType variations, color font formats: COLRv0, SBIX, CBDT) on all OSes where we have our own engine (iOS excluded). This means we would not reveal any font technology support differences using this feature as we can cover the gaps with the Skia+FreeType backend.

However, at the specification level, conceptually, this feature can reveal more than the user agent major version if in non-Chrome implementation platform font support differs and a UA provides different support on different platforms. Firefox, as an example, does not have a hybrid font stack capability so their font technology support differs on different platforms. So a correct implementation of this feature in a UA that supports some font technologies only on some platforms would reveal information about the underlying OS/platform as well - so the granularity is similar to UA major version + platform (Win, Mac, Linux, etc.).

Relationship to server side negotiation

During the discussion on blink-dev the question was brought up by @yoavweiss in how this feature compares or relates to

• server-side content negotation techniques such as the Accept: header or client hints
• preload optimizations with their type attribute for pre-requesting resources.

Server-side content negotiation at the time of requests to font blobs or CSS stylesheets are additional tools for selecting the right font content. Preload optimisations as well.

We concluded that there is room for improvement for server side negotiation when requesting font resources. Currently, third-party font providers such as Google Fonts make use of user agent information to decide what CSS to ship. Additional discussions showed that improving this server-side content-negotiation should likely be done through extending UA client hints to give indication about supported font technologies. We concluded that mapping a set of font-technologies supported by the UA to a set of mime-types is likely not a good approach.

In any event, both (server-side content negotiation, preload optimizations) and client side content selection of font resources through the advanced @font-face src: ..supports(<font-technology>) syntax provide useful tools at different stages of fetching and rendering content, which both serve different needs.

Quote from @yoavweiss on blink-dev:

I was initially concerned by the fact that these technologies are not well represented in the relevant mime type that can then be used for selection in preload and as part of the Accept header.
But given the fact that preload's type based selection is breaking at the seams when it comes to image types as well as in the face of many different font features, with different levels of support across browsers, it seems like it may be time to design a separate selection mechanism there that wouldn't rely so heavily on mime types.
Regarding Accept, after further thinking, I was not excited about adding the font capabilities to that header because: a) it may expose more passive entropy b) the content-negotiation for fonts is often needed when serving the stylesheet, and sending Accept values for fonts as part of the stylesheet request felt weird. Talking to the Privacy Sandbox folks, they seem to generally agree with (a) and that we may need an alternative mechanism to enable font capabilities based content negotiation.

As such, I think it's fine that this feature is considering the various font capabilities as an orthogonal dimension to font formats and enabling client-side content-negotiation based on that. That seems like an important use case.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @yoavweiss @svgeesus @jfkthame

[kenchris]

Congratulation on making review request #666 😈👿 This now has a milestone

[atanassov]

Hi @drott, similar to other design reviews, can you add an actual explainer to this review? Having well articulated user needs and scenarios, the different approaches you considered and how this proposal addresses these is valuable to the review and for posterity.

[drott]

Hi @drott, similar to other design reviews, can you add an actual explainer to this review?

Explainer added to edited description, available at https://github.com/drott/format-supports-explainer.

[svgeesus]

Explainer added https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md

[svgeesus]

Huh, great minds think alike, eh? 🤣

[drott]

Oups, I was just about to email you. Thanks so much for this! Yours looks better, I'll do a pull request with some suggestions in regards to the detectability aspect and non-goals.

[svgeesus]

Mine is maybe better on history, yours is better on the detectability and non-goals

[atanassov]

Wow, thank you both for all the explanations! :)

We like the general use cases and proposed direction of this feature. However we're concerned about the replication of an existing feature, so before shipping we hope that you will work with the CSS Working Group to exhaust any existing CSS feature detection mechanisms such as @supports (see w3c/csswg-drafts#6520 as proposed example) before going after a new microsyntax solution.
FYI, the TAG is working on adding an explicit guidance discouraging new microsyntax from being added (see w3ctag/design-principles#213).

Thank you for working with us. Good luck.

[svgeesus]

For those following along at home the two explainers have now been merged