Google Groups

Intent to Ship: Font Load Events

Kenji Baheux Feb 4, 2014 1:30 AM
Posted in group: blink-dev

Primary eng (and PM) emails (



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)?


Demo link


  • 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

Compatibility Risk

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

OWP launch tracking bug?

Link to entry on the feature dashboard


In M34, the implementation will most likely have the following minor limitations:

  • FontData construction from BinaryData won’t be available in M34

  • The coherence of FontFace, @font-face rule, and font matching engine upon property changes might not be guaranteed in M34

We believe that even with these limitations, the API is extremely valuable and effectively solve the most important use cases. In any event, these limitations will be addressed in M35.