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

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Explainer

https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/font-tech-format-explainer.md

Specification

https://www.w3.org/TR/css-conditional-5/#at-supports-ext

Summary

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 (https://pixelambacht.nl/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.

Motivation

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().

Examples:

• 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

Blink>Fonts

TAG review

https://github.com/w3ctag/design-reviews/issues/666

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Gecko: In development (https://github.com/mozilla/standards-positions/issues/563#issuecomment-1224131600) 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:

Ergonomics

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.

Activation

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?

No.

Debuggability

Equivalent to other @supports debugging.

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

Yes

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

chrome://flags/#enable-experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1255685

Sample links

https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/font-tech-format-explainer.md#use-case-1---progressive-enhancement-with-color-fonts

Estimated milestones

108

Anticipated spec changes

Additional keywords may be added in the future.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5155718374621184

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBvYtHHtgDGtJ-7j%3DJdzWTOA8MFf8O6VT%3DOyovcfYihmog%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

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

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/af6ad6e4-ada1-8035-0924-9aa28d0af32e%40gmail.com.