Intent to Ship: font-tech() and font-format() condition extensions to CSS @supports

Skip to first unread message

Dominik Röttsches

Sep 19, 2022, 7:47:04 PM9/19/22
to blink-dev

Contact emails




The font-tech() and font-format() are extensions to the @supports rule CSS Conditional Syntax enable declarative and programmatic access to feature detection of font stack features. Using these conditions together with @supports allow progressive enhancement of content depending on font format support. In particular with UAs differing in support for color font formats, this is useful for including color font style rule and @font-face definitions only if the user agent supports it. Using JS CSS.supports() calls this is also the first ergonomic way of testing for font stack capabilities on the web without UA sniffing or canvas pixel readback as in Chromacheck (

This feature is closely related to the @font-face src: descriptor syntax extension which was recently discussed and LGTM'ed here: - the same font format and technology keywords are used and synchronized between these two features.


While font files look the same from the outside in their mime type and file signature, they may contain information that requires specific features of the UA's font stack.

If an author wants to progressively enhance their site depending on font format capabilities of the UA, feature detection is needed. This feature here provides such a capability on the client side in two ways, declaratively in CSS, or programmatically in JS using CSS.supports().


  • If OpenType variations are supported, I want to use a set of different style rules than when variations are not available
  • If color font support is available, I want to enhance my site with a color fonts plus style rules affecting other parts of my page.

Blink component


TAG review

TAG review status

Issues addressed


Interoperability and Compatibility

Gecko: In development ( Implemented behind flag and standards position concluded with positive stance towards this feature. Jonathan Kew plans to ship this soonish and in any case in sync with COLRv1 support.

WebKit: From the standards discussion on this, my take-away of the discussion with Myles is that the feature is useful, but Myles suggests to ship it only in combination with @else - my position is that @else is not essential for this feature to provide value.

Web developers: Positive Feedback we received from partners is that robust feature detection for this feature is a requirement and helps activation of usage of color fonts. More info available internally. (See previous I2S for tech() and format() in the src: descriptor of font-face)

Other signals:


This feature is intended for situations where the progressive enhancement choice is made client side. Feature detection on the server side, at the time for example the UA makes a request for a style sheet is out of scope for this proposal. In those situations, UA sniffing on the server side is still performed on the server based on request headers and user-agent string - which may be addressed by font feature client hints in the future.


Low: If this feature is not supported, the respective CSS styles are not included, so the progressive enhancement fails, which is the nature of this approach. If CSS.supports() calls are failing because they are not available, then the program logic trying to feature detect font stack capabilities, may need to resort to other methods of testing font support, for example through Canvas pixel probing or hardcoded UA lists.

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?



Equivalent to other @supports debugging.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


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

Yes, tests were added by Mozilla's Jonathan Kew initially while developing support for this feature in Gecko with additional tests and modifications to them when I developed the feature behind a flag.

Flag name


Requires code in //chrome?


Tracking bug

Sample links

Estimated milestones


Anticipated spec changes

Additional keywords may be added in the future.

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Yoav Weiss

Sep 21, 2022, 1:40:26 AM9/21/22
to Dominik Röttsches, blink-dev
LGTM1 - thanks for following up on the TAG's feedback!

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
To view this discussion on the web visit

Daniel Bratell

Sep 21, 2022, 6:45:46 AM9/21/22
to Yoav Weiss, Dominik Röttsches, blink-dev

Mike Taylor

Sep 21, 2022, 11:24:27 AM9/21/22
to Daniel Bratell, Yoav Weiss, Dominik Röttsches, blink-dev
Reply all
Reply to author
0 new messages