Events and interfaces used for dynamically loading font resources.
Link to “Intent to Implement” blink-dev discussion
N/A (the intent to implement this API predates blink; the corresponding crbug entry was filed back in 2010!).
According to HTTP Archive, ~37% of the top 300K sites are using web fonts. This represents more than a 2x y/y increase. This is great for several reasons ranging from improved accessibility and searchability to high-DPI friendliness and obviously much greater expressiveness.
Unfortunately, when you start to rely on web fonts you quickly realize the limitations of the platform:
you have to use fragile hacks to gain insights about the actual availability of your web fonts
you have no control over the user experience:
all the font requests are blocked on DOM and CSSOM so that the browser can determine which web fonts are needed by the document. As the designer, you most likely know which web fonts are critical but you can’t tell the browser about it.
some browsers will fallback on a system font immediately, some will fallback after a 3 seconds timeout and others would be happy to wait forever after a web font.
The Font Load Events API gives you control and insight into how and when the fonts are loaded. For instance, you can check beforehand if all the necessary fonts are readily available, or schedule font downloads at will and do something when they are ready.
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Open in Incognito to guarantee that you start from a fresh cache
unless you are on super fast connection, you should see a page with a bland choice of web fonts
Open one more time the demo page in a second tab
web font galore!
What the demo does:
kicks web font downloads as soon as possible with the load() method
before the page is rendered, it checks if all the fonts are ready with the check() method
if all the web fonts are ready then it changes the style to take advantage of said web fonts
This is a bucket 4 item: “The specification for the feature has been accepted by the appropriate standards working group (e.g., a First Public Working Draft in the W3C) and we’ve received positive feedback from other browser engines about the feature’s feasibility and value.”. Concretely, Mozilla sees the value provided by this API and is generally supportive (bugzilla).