Intent to Implement: CSS font-display
Kenji Baheux
Contact emails
Engineering: ksak...@chromium.org
Spec editors: taba...@chromium.org , kenji...@chromium.org
Spec
https://tabatkins.github.io/specs/css-font-display/
Summary
A new @font-face descriptor for controlling how a downloadable font renders before it is fully loaded.
Motivation
When using downloadable webfonts via @font-face, the user agent needs to know what to do while the font is actively loading. Most web browsers have adopted some form of timeout:
Browser | Timeout triggering fallback behavior | Fallback to system font? | Swap when the web font is available? |
Chrome 35+ | 3 seconds | yes | yes |
Opera | 3 seconds | yes | yes |
Firefox | 3 seconds* | yes | yes |
Internet Explorer | 0 seconds | yes | yes |
Safari | no timeout | n/a | n/a |
*: simplified view
The 3 seconds timeout is from the point where the user agent determined that a particular web font would be needed. Synthetic example:
Font Loading API allows a developer to override some of the above behaviors, but that requires scripting, a non-trivial amount of effort, and ultimately doesn’t provide sufficient hooks to cover all reasonable cases. Additionally, the developer needs to either inline the loading script into their page, or else load an external library and introduce additional network latency before the fonts can be loaded, delaying text rendering.
Design/performance-conscious web developers have a good sense for the relative importance of a given web font for the intended user experience. This specification provides them the ability to control font timeout and rendering behavior. Specifically, it lets developers:
Define the font rendering strategy when text is ready to be painted: block, or paint with fallback.
Define the font rendering behavior once the desired font is available: rerender text with the new font, or leave it with the fallback.
In addition, providing our developers a simple mean to control the behavior is important in the following context:
user agent interventions such as “bailing out early on web fonts if we know that we'll hit the font timeout anyway” (assuming an absence of conflicting font-display directives; crbug; discussion thread on intervention-dev coming soon).
RAIL performance because publishers currently have to rely on third party font loaders to approximate some of these behaviors, which further delays the first meaningful paint (with/without web fonts).
Compatibility Risk
Medium.
Pluses and minuses:
- no browser implementation at the moment
+ small API footprint
+ sufficient level of consensus in the CSS working group for the purpose of this intent to implement
- the specification is not yet integrated in the CSS font level 4 specification or a CSS specification
= no major negative and unaddressed feedback from other browser vendors
+ high level of interest from developers:
https://speakerdeck.com/smashingmag/improving-web-fonts-performance
https://speakerdeck.com/zachleat/the-performance-and-usability-of-font-loading
https://speakerdeck.com/bramstein/the-consequences-of-web-fonts
and my favorite: “CSS font-display property is going to solve all of our font loading woes ― Patrick Hamann”.
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/4799947908055040
Requesting approval to ship?
Not yet.
Yoav Weiss
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
PhistucK
Kenji Baheux
Kenji Baheux
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
