Intent to Implement: Default font-display in @font-feature-values
Rune Lillesveen
Contact emails
kenji...@google.com, fut...@chromium.org
Design doc/Spec
https://drafts.csswg.org/css-fonts-4/#font-display-font-feature-values
Summary
Add support for parsing @font-feature-values accepting a font-display descriptor. That font-face descriptor will be used as a default font-display value for @font-face rules which do not have a font-display descriptor - matching the font-family of @font-feature-values. We need to resolve spec and compat issues before considering shipping this. It's not even sure this will be added syntactically in @font-feature-values, but we would like to experiment with an implementation behind a flag.
Motivation
A lot of web fonts deployments are handled by third party services. The most popular ones rely on link rel=stylesheet as their integration snippet. This is problematic for font-display given that it's meant to be added into the @font-face definitions while developers don't have control over these definitions as they are provided by these services via the link rel=stylesheet snippet. While it's conceivable that these third party services could allow the customization of font-display via URL parameters, in practice it doesn't happen because it would negatively impact the cacheability of these stylesheets.
Risks
Interoperability and Compatibility
No other engines have implemented this and there is a debate whether @font-feature-values is the right place for this [1]. There is also an issue that FIrefox implements @font-feature-values taking a <rule-list> as currently specified which means mixing in descriptor syntax at the same level (as the section for font-display indicates) will cause compat issues with Firefox - also noted in [1].
[1] https://github.com/w3c/csswg-drafts/issues/2973
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5652297006710784
Requesting approval to ship?
No.
superp...@gmail.com
I understand font-display in @font-feature-values is a recommended feature to control display of fonts when you have no direct control of the @font-face block such as loading from Google Fonts.
However, it doesn't seem to specify what happens if the browser doesn't see the @font-face yet.
For example, I might use rel="preload" for Google fonts and the browser might start painting the page before the css is downloaded.
Suppose I use
font-display: block;
inlined in the HTML.
Would the browser show invisible text or the fallback font?
This question arises because it may have been assumed that the css is loaded synchronously in which case painting doesn't occur until the css is downloaded and parsed in which case both font-feature-settings/font-display and the @font-face block is known to the browser and in this case fallback font isn't used.
Cannot assume this if css is preloaded.