[w3ctag/design-reviews] Review Reqest: CSS Fonts src: descriptor syntax for client side font selection (#666)

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](https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing) 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](https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing) 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 provide desired feature detection capabilities before the introduction of the [COLRv1 font format](https://github.com/googlefonts/colr-gradients-spec). 

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

  - Explainer¹ (minimally containing user needs and example code): Not available, part of existing spec. Example of feature detection in https://chromium-review.googlesource.com/c/chromium/src/+/2940647

  - 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](https://github.com/w3c/csswg-drafts/issues/633) in the CSS WG.
  - Key pieces of existing multi-stakeholder review or discussion of this specification:
     - [CSS WG Resolution for issue #633](https://github.com/w3c/csswg-drafts/issues/633) initially adding `format()` and `supports()` syntax
     - [CSS WG change in issue #6340](https://github.com/w3c/csswg-drafts/issues/6340) to clarify parsing rules for `supports` syntax
     - [blink-dev intent to ship thread](https://groups.google.com/a/chromium.org/g/blink-dev/c/bCA9H3eaO3s/m/gDrJ0Mx-AAAJ)
  - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
    - https://crbug.com/1216460


Further details:

  - [x] I have reviewed the TAG's [Web Platform Design Principles](https://w3ctag.github.io/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.

We'd prefer the TAG provide feedback as:

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


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/666