Intent to Ship: supports <font-technology> for the @font-face src: descriptor

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Specification

https://drafts.csswg.org/css-fonts/#font-face-src-parsing

API spec

Yes

Summary

Support the extended `supports <font-technology>` syntax of the @font-face src: descriptor. The intention of this syntax is to enable UA's to choose supported entries from the src: line of the @font-face. Unsupported entries with "support..." lines which are not supported are to be dropped from the src: line.

Motivation

Supporting this syntax enables an inexpensive CSS or JS based check for support of CORLv1 or other font technologies.

CSS based selection of the right font and technology is done by the UA traversing the src: line and choosing the first successfully parsed and supported entry and trying to load it. If the load fails, the next supported entry is chosen.

JS feature testing can be achieved by declaring a CSS @font-face in a stylesheet with a src: line that contains for example a line src: format(woff2) supports COLRv1; - then accessing this rule using CSSOM and retrieving the value of cssText for this rule. By analysing the values of cssText, specifically the serialized src: line, it can be determined whether entries were dropped from the src: line.

Support for this feature across browsers allows precise selection of the best, supported font technology from the @font-face definition.

Blink component

Blink>Fonts

Search tags

css, @font-face, src, descriptor, src descriptor

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The `supports <font-technology>` is a backwards-compatible extension of the @font-face src: descriptor syntax. Existing values for the src: line which contain only string values such as format("woff2") for format("woff2-variations") will still be understood and working as intended. The CSSOM serialisation of the parsed value will be canonicalised to match the spec grammar. E.g. if the page specifies src: url(...) format("woff2") supports variations; it will be serialized as src: url(...) format(woff2) supports variations; to upgrade the syntax to the newer form in the spec. I expect low compatibility problems from that, because a) the format() syntax is not often used, b) I do not expect the serialisation of the value to be accessed much at all.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=650372)

WebKit: No signal (https://github.com/w3c/csswg-drafts/issues/633) Case made for "supports" syntax originally made my Myles Maxfield from Apple. Nevertheless, "supports" syntax extension not implemented in Safari yet.

Web developers: Positive
When working on COLRv1, we've received requests from prominent web partners for an efficient way of feature testing for COLRv1 availability. Implementing the supports syntax allows JS and CSS based feature detection for COLRv1.

Ergonomics

The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.

Debuggability

To some extent through DevTools. (Not much support exists for @font-face in general)

Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.

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

No, WPT tests will be added while completing implementation work of this feature.

Tracking bug

https://crbug.com/1216460

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5741063488667648

[Yoav Weiss]

/me takes off API owner hat and puts on my webperf person hat instead

I think it would make more sense to define those different font technologies as new MIME types or extensions to existing ones.

That would enable performing that content negotiation on the client (by changing "format()"), on the server (using Accept headers) as well as enable preload support (for the latest variant), using the `type` attribute.

Even if extending the MIME types is not the right way to go, we need to think about those cases and make sure they are supported.

Have y'all talked to folks that serve fonts using content negotiation?

--
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/CAN6muBvJEc2pa1_pRWBSEktxHSEz_SnwjSyETVdoqpS_MXT1Gg%40mail.gmail.com.

[Dominik Röttsches]

Hi Yoav,

Thanks for the feedback.

On Mon, Jun 21, 2021 at 3:19 PM Yoav Weiss <yoav...@chromium.org> wrote:

/me takes off API owner hat and puts on my webperf person hat instead

I think it would make more sense to define those different font technologies as new MIME types or extensions to existing ones.

That would enable performing that content negotiation on the client (by changing "format()"), on the server (using Accept headers) as well as enable preload support (for the latest variant), using the `type` attribute.

What do you mean by preload support, "latest variant" and "type attribute" here? 

Even if extending the MIME types is not the right way to go, we need to think about those cases and make sure they are supported.

Have y'all talked to folks that serve fonts using content negotiation?

There's been the start of a discussion, yes, we had a thread with Mike Taylor and input from Evan Adams of Google Fonts on this. I've been wondering whether something like UA client hints for font formats would be the right method and useful addition for content negotiation (disclaimer: I am not very familiar with client hints yet and may lack sufficient understanding.)

I don't think extending MIME is the right way as what we're looking at in terms of formats is at a different level: the overall font format and high level file structure does not change between formats. Font formats in this respect here differ at the font table level within an overall similar file structure.

At this point, the "supports <technology>" syntax is something that's defined in the spec and has been through spec discussions already and serves as one way for COLRv1 feature detection. It's something that's immediately implementable and doable right now to unblock feature detection for this new format.

Developing such a useful new way of content negotiation for font formats at the request/header level would be a longer specification process worthwhile starting. 

As we have requests for feature detection for COLRv1 if possible, I would prefer not to block on that for shipping COLRv1 color fonts.

Dominik

[Yoav Weiss]

On Mon, Jun 21, 2021 at 6:20 PM Dominik Röttsches <dr...@chromium.org> wrote:

Hi Yoav,

Thanks for the feedback.

On Mon, Jun 21, 2021 at 3:19 PM Yoav Weiss <yoav...@chromium.org> wrote:

/me takes off API owner hat and puts on my webperf person hat instead

I think it would make more sense to define those different font technologies as new MIME types or extensions to existing ones.

That would enable performing that content negotiation on the client (by changing "format()"), on the server (using Accept headers) as well as enable preload support (for the latest variant), using the `type` attribute.

What do you mean by preload support, "latest variant" and "type attribute" here? 

Apologies for not being clearer... 

"preload support" - ability to preload such fonts with supported features in supporting browsers, and not preload them in non-supporting ones.

"latest variant" - preload currently doesn't have support for "don't load this resource if you do support this feature" semantics. That means that you could use preload to load the most common or latest supported feature (e.g. variable fonts), but won't be able to use it to preload a different variant in browsers that don't support that feature.

"type attribute" - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-type

 

Even if extending the MIME types is not the right way to go, we need to think about those cases and make sure they are supported.

Have y'all talked to folks that serve fonts using content negotiation?

There's been the start of a discussion, yes, we had a thread with Mike Taylor and input from Evan Adams of Google Fonts on this. I've been wondering whether something like UA client hints for font formats would be the right method and useful addition for content negotiation (disclaimer: I am not very familiar with client hints yet and may lack sufficient understanding.)

I think it may be interesting to revamp content negotiation and base it on Client Hints, especially as `Accept` based headers are getting longer and longer.

At the same time, `Accept` based negotiation is still very much a thing, and we shouldn't leave it aside.

Also see https://github.com/w3c/woff/issues/2

 

I don't think extending MIME is the right way as what we're looking at in terms of formats is at a different level: the overall font format and high level file structure does not change between formats. Font formats in this respect here differ at the font table level within an overall similar file structure.

One of the biggest mistakes with webp adoption (IMO) was that new features were added to the format without changing its MIME type. That resulted in deployment issues (e.g. with old Android that only supported part of the features), forcing image CDNs to fallback to UA sniffing and other inaccurate methods.

[Yoav Weiss]

/me puts his API owner hat back on

I think this can benefit from a TAG review. 

Resolution here seems like something that would impact issues on preload, fonts as well as content negotiation solutions. That doesn't seem like something the CSSWG can decide on unilaterally.

I'd love for the TAG to weigh in and decide if format features is something that needs to be expressed as a variation of MIME types or on a completely separate dimension. If it's the latter, we need to see how we integrate that separate dimension to preload (`supports` attribute?) and to the Accept header (or an alternative Client Hints based solution).

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The `supports <font-technology>` is a backwards-compatible extension of the @font-face src: descriptor syntax. Existing values for the src: line which contain only string values such as format("woff2") for format("woff2-variations") will still be understood and working as intended. The CSSOM serialisation of the parsed value will be canonicalised to match the spec grammar. E.g. if the page specifies src: url(...) format("woff2") supports variations; it will be serialized as src: url(...) format(woff2) supports variations; to upgrade the syntax to the newer form in the spec. I expect low compatibility problems from that, because a) the format() syntax is not often used, b) I do not expect the serialisation of the value to be accessed much at all.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=650372)

WebKit: No signal (https://github.com/w3c/csswg-drafts/issues/633) Case made for "supports" syntax originally made my Myles Maxfield from Apple. Nevertheless, "supports" syntax extension not implemented in Safari yet.

Web developers: Positive
When working on COLRv1, we've received requests from prominent web partners for an efficient way of feature testing for COLRv1 availability. Implementing the supports syntax allows JS and CSS based feature detection for COLRv1.

Ergonomics

The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.

Debuggability

To some extent through DevTools. (Not much support exists for @font-face in general)

Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.

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

No, WPT tests will be added while completing implementation work of this feature.

Tracking bug

https://crbug.com/1216460

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5741063488667648

--
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+unsubscribe@chromium.org.

[Mike West]

Friendly ping on Yoav's suggestion. Did y'all ask the TAG to weigh in?

-mike

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/CAN6muBvJEc2pa1_pRWBSEktxHSEz_SnwjSyETVdoqpS_MXT1Gg%40mail.gmail.com.

--

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/e5a7290d-4897-42fe-a069-db7581dc89f9n%40chromium.org.

[Kaustubha Govind]

Hi Dominik,

I was wondering 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)? If not, would it be possible to add some text to the Security & Privacy Considerations section to indicate that browsers shouldn't use a minor version of the OS they're running on to decide whether a font feature is supported? This is to ensure that this feature cannot be used as a fingerprinting surface.

Thank you,

Kaustubha

[Mike West]

Friendly-pinging my friendly-ping on Yoav's question. :) Is this intent still active?

-mike

[Dominik Röttsches]

Hi Mike, Kaustubha,

Friendly-pinging my friendly-ping on Yoav's question. :) Is this intent still active?

 

This intent is still active, sorry for the delay in responding. Yoav and I were both out-of-office in overlapping periods of time. For myself, I was out the past two weeks and did not file the TAG review request before that. My intention was to have a 1:1 conversation with Yoav before I do that to align first. 

On Tue, Jul 13, 2021 at 8:04 PM Kaustubha Govind <kaust...@google.com> wrote:

I was wondering 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)? If not, would it be possible to add some text to the Security & Privacy Considerations section to indicate that browsers shouldn't use a minor version of the OS they're running on to decide whether a font feature is supported? This is to ensure that this feature cannot be used as a fingerprinting surface.

I think the answer to your question 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 rasterizing capabilities (DirectWrite, CoreText) combined with Skia +FreeType's rasterization capabilities to fill in gaps in the system rasterizer. 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.).  

Dominik

[Dominik Röttsches]

As a quick update, Yoav and I had a good discussion which - at least I can speak for myself - really helped improve the mutual understanding. There's a few things we want to ask Google Fonts and other third-party font providers in terms of how clues in an Accepts: header might be useful for them for delivering the right CSS before we come back to resuming this intent to ship.

Dominik

[Yoav Weiss]

Dominik and I had a few discussions over the last few days which clarified the direction we want to take with font technologies and related content negotiation.

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.

I think it'd make sense to ask for explicit signals from both Mozilla and Apple: bit.ly/blink-signals 

Web developers: Positive

Any links to artifacts of positive developer opinion?

 

When working on COLRv1, we've received requests from prominent web partners for an efficient way of feature testing for COLRv1 availability. Implementing the supports syntax allows JS and CSS based feature detection for COLRv1.

Ergonomics

The CSS based selection of the font src: of the right technology works without ergonomic issues and is the spec-suggested approach for solving this problem. The JS based feature detection as described above is a more efficient check for supported font technology than using a canvas-based approach as for example used in https://pixelambacht.nl/chromacheck/. At the same time, it's still not as straight-forward compared to CSS.supports() JS syntax. However, CSS.supports() works only for CSS properties, not for descriptors of @font-face. In that sense, this is a spec-compliant approach that can be deployed now, while the spec discussion continues on whether a more direct JS based feature test for descriptor syntax should be added.

Debuggability

To some extent through DevTools. (Not much support exists for @font-face in general)

Not supported src: entries will be removed from the src: line and will not show up in DevTools. As such, DevTools helps to identify which types of entries are supported and how parsing of the src: line succeeded.

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

No, WPT tests will be added while completing implementation work of this feature.

I'm assuming it will be tested before shipping. Is that a correct assumption?

[Dominik Röttsches]

Hi Yoav,

On Fri, Jul 30, 2021 at 8:00 PM Yoav Weiss <yoav...@chromium.org> wrote:

Dominik and I had a few discussions over the last few days which clarified the direction we want to take with font technologies and related content negotiation.

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.

Thanks for the discussion and this feedback. 

As you also suggested to still do a TAG review, as we'd be the first to ship this feature, I filed a TAG review for the extended @font-face src: supports() syntax.

I think it'd make sense to ask for explicit signals from both Mozilla and Apple: bit.ly/blink-signals 

Filed as 

https://lists.webkit.org/pipermail/webkit-dev/2021-August/031935.html for WebKit and

https://github.com/mozilla/standards-positions/issues/563 for Mozilla. 

Myles from Apple has been quite active in developing this syntax, compare CSS WG issue 633, which makes me hopeful that Apple has a positive stance towards this feature even though it's not shipping in Safari yet.

Any links to artifacts of positive developer opinion?

No public links, I have meeting minutes from speaking with partners, if that helps. 

I'm assuming it will be tested before shipping. Is that a correct assumption?

Yes, of course. I'll develop WPT tests. 

Dominik

[Dominik Röttsches]

Hi,

another update:

• The TAG review is now completed with positive feedback on the feature direction and recommendation to investigate whether a CSS Fonts specific micro-syntax can be avoided for example using a nested @supports syntax inside @font-face. TAG's wording:

"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."

• A positive signal on the feature from Apple: webkit-dev thread 

I'll investigate whether the proposal to use @supports inside @font-face is feasible and whether it adds too much complexity, then respond on the respective CSS WG issue 6520 and see if we can conclude the discussion in the CSS WG and either agree on a new TAG friendly syntax or conclude that the existing micro-syntax is needed. 

Once that's done, I'll come back to this Intent To Ship. 

Dominik

[Joe Medley]

Which milestone are you aiming for?