While this section of the specification was not actually present until 2011, it’s useful in framing the current font loading landscape. Some time in 2009, Firefox and Opera began shipping
@font-face
support with the former behavior: text would render with fallback fonts until downloadable font resources became available. But this choice frustrated many users (see the Firefox bug report) and was quickly dubbed FOUT, the Flash of Unstyled Text. Articles were written about fighting the@font-face
FOUT. It wasn’t long before most browsers were hiding text while fonts downloaded.Unfortunately, the main issue with
@font-face
now is what many wanted to avoid years ago: the FOIT, or Flash of Invisible Text.Fallback fonts have been specified, but many browsers dictate that text should remain transparent until Open Sans has been downloaded or fetched from browser cache. Many Webkit browsers will wait 3 seconds before timing out and showing the fallback. Some browser may wait as long as 30 seconds, turning the flash of invisible text into an eternity for users on extremely slow network connections.
Chris Manning
It always perplexed me how web developers and standards went from a less than ideal, but acceptable experience (fonts changing during page load) to the current broken, user-unfriendly experience (text not rendering at all until custom web fonts are downloaded). Custom fonts are nice elements of design, but if this interferes with content – especially all-important titles – site owners should prioritize content over design; after all, most people browse the web for content, not to admire the typographic skills of designers. The problem may soon become more pressing, as the recently-launched ad-blockers for iOS offer the option of blocking custom fonts as well, forcing designers to work with built-in fonts for proper fallbacks in case webfonts are disabled.
Here’s a good overview of the issues and some ways for developers to solve these problems in current and future browsers:
Post a Comment