I last wrote about the progress of webfonts for A List Apart six years ago. Very few sites used webfonts then, but there was a lot of pent-up frustration among designers to get moving after 15 years of confinement to so-called “web-safe” system fonts.
And move they did. With the learn-as-you-go self-reliance that web creators have always been so good at—a slick change in syntax to grease this thing here, a polyfill to patch that thing there—we’ve come a long, long way with very little preparation.
A success by anyone’s measure (mostly)#section1
As of May 2016, a majority of sites—60% of the Alexa Top 1 Million Sites—were using webfonts, up from only 2% in 2011.
In “Efficient Web Type, Circa 1556”, designer Kenneth Ormandy notes that “we are building sites that request more fonts, from an 8kb average transfer size at the beginning of 2012 to a 59kb average two years later.”
Data also shows that soon after a site adopts webfonts, it will likely add more: the number of requests go up and, so too, do the sizes of the files requested. An exodus away from system fonts is clearly underway. Webfonts have reached critical mass and will soon be the new normal in web typography.
Now, whether webfonts, cloud computing, or animation, the adoption of new technologies means potential users have come to terms with their fears about them. These fears can be very irrational, and they can persist long after the conditions that gave rise to them are gone. For example, in 2009, web performance expert Steve Souders—then at Yahoo—warned web designers that they should, if at all possible, stay away from webfonts: “My first piece of advice is to avoid using @font-face unless it’s critical to the page.”
Whoa. Okay, but that was back then. This is 2016. With usage at 60 percent, surely nobody would seriously argue for a return to system fonts, right?
Just say no#section2
He goes on:
In sum, Morse’s attitude is that web fonts aren’t worth the trouble they cause some users—especially in low-bandwidth conditions—and that sticking with tried-and-true system fonts is best for all concerned.
Well. In less time than it takes to say “Holy holdout, Batman!” web designer Robin Rendle posted a rebuttal. A few days later came Frederic Marx’s “Webfonts Last”. And in between those volleys, both Jeffrey Zeldman and Jeremy Keith took note of the disturbance in the force and I, sucked into the vortex, offered to write this article. C’est le web.
Morse’s criticisms obviously hit a sore spot with Robin Rendle and Frederic Marx and, frankly, me too. But why so touchy after all this time? Webfonts are a runaway train and anyone standing astride the tracks shouting stop is just asking to get plowed over. Didn’t everybody get the tweet about this? Well, maybe not—maybe some people genuinely aren’t aware that webfonts have become so popular.
As Rob Larsen observes in his book The Uncertain Web:
But then, also, maybe there’s some truth to what Morse is saying.
Morse is right to rail against webfonts’ drawbacks. A poor user experience for some of us diminishes all of us. Leave no user behind—who would argue with that? Plus, the browser makers and the W3C have taken too long and have done too little to give web designers the fundamental tools, within CSS alone, to ensure consistent behavior from browser to browser. A standards-based fix is long overdue.
font-display property proposed by Tab Atkins, Jr. of Google is an attempt at just such a fix.
Atkins lists some of the persistent problems his proposal addresses:
Now, amazingly, jaw-droppingly, these defects are consistent with the very same defects described in Souders’ analysis from 2009—seven years ago!—in which he advised, from a webperf analyst’s point of view and with a webperf analyst’s priorities, that webfonts not be used at all.
Yet the pain of still more Arial, still more Helvetica, proved too much to bear when, at long last, webfonts started looking like a practical option in early 2011. Web design featuring a wide variety of typefaces that were searchable, scalable, zoomable, selectable, and high-DPI friendly was too great a temptation to resist. Scary talk be damned, designers inched forward on their own, saw for themselves, and, in the collective view of the two percent of early adopters, despite a few kinks and blinks—c’mon, is it really a “flash” of unstyled content?—webfonts by and large worked well enough to begin leaving the homogeneity of system fonts behind.
But infatuation will only take you so far. Those early adopters were able to keep moving steadily forward and draw others into the fold only because conditions became increasingly amenable to webfonts. The timing was right.
Like manna from heaven#section4
It’s 2011, and for webfonts to start taking hold, backward compatibility with Internet Explorer is essential. It’s hard to imagine any site giving webfonts a try if it means excluding the huge number of IE 6, 7, and 8 users that existed then. The catch was, with any version of IE prior to version 9, the webfont had to be converted from a TrueType font (TTF) to the Embedded OpenType (EOT) format. Then, the HTML had to include CSS that accommodated both the rudimentary implementation of
@font-face that went all the way back to the release of IE 4 in 1997 and also, at the same time, work with the newer syntax demanded in CSS3. Several workarounds emerged, but in the end there was a clear winner: the New Bulletproof Syntax was a clever, yet simple, CSS-only solution to the problem. It’s still in wide use today.
And so, greatly favorable to the adoption of webfonts—perhaps above all else—and yet easily overlooked because it came gradually and in small doses—was more bandwidth, more bandwidth, and then more bandwidth. The average internet speed in the United States today is three times as fast as it was in 2011.
Progressive enhancers need not apply#section5
Webfonts are sometimes presented as “progressive enhancements” of system fonts. That’s incorrect. System fonts are a parallel solution to the same problem. A webfont is not an “enhanced” version of a system font, nor is a system font a gracefully degraded webfont. It might feel that way because, if a webfont is not available, the browser falls back to a system font. But fallback fonts are system fonts that vary according to which platform the browser is installed on; there is no way to know precisely which font—or version of the font—the browser will fall back to. As any web server administrator will tell you, the only content you can be absolutely sure of is what’s on your server. Everything else is guesswork. In fact, to get webfonts working well, the exact opposite of progressive enhancement is required.
Morse is right that, without extra effort, CSS by itself doesn’t give us the tools to smooth out the user experience as webfonts load (or don’t). But we can achieve that level of control with just a little bit of extra work—well-tested remedies and refinements exist for all of the problems Morse implicitly treats as insurmountable. Typekit’s Bram Stein, Filament Group’s Zach Leatherman, and Google’s Ilya Grigorik have all prominently posted solutions to these problems online. The truth is out there, Scully.
Amen. Which leaves us with the final reason why Morse’s criticisms are beside the point. He puts an unquestioning, almost religious, faith in system fonts.
In his rebuttal to Morse, Rendle notes:
It’s a fact. Ask yourself this: if network bandwidth had been able to support the requisite file sizes when the web began, wouldn’t fonts sent from the server have been greatly preferred over system fonts? If you can only be certain of what’s under your control on your server, which would you rather have—the certainty of webfonts that are precisely what you and your users want and need, or the crapshoot of fonts preinstalled by makers of operating systems that present you with moving targets that vary from platform to platform? So-called “web-safe” system fonts were a temporary ad hoc solution that web designers had no choice but to accept because network bandwidth was not yet capable of delivering what would, sooner or later, be necesary for the web to take its place as a truly global tool. Webfonts—the ones designers choose—are the true “web-safe” fonts. They always were. If ever there was a time when, by chance, system fonts offered a safe and simple haven for web designers, those days are long gone.
The challenge of multi-script fonts#section6
Most of the fonts Google commissioned in 2015 were Indic—Devanagari, Bengali, Gujarati, Gurmukhi, Kannada, Myanmar, Sinhala, Telugu, Tamil, and Malayalam—along with Arabic, Hebrew, Ethiopic, Armenian, Cyrillic, Cherokee, Lao, Khmer, and Thai. On Google Fonts’ redesigned site, you’ll see new menu items with those choices. The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest. There’s a great hunger for the web to accommodate the world’s 6,000+ languages; a way to fulfill that need has finally taken shape through a convergence of three key developments:
- the rise of Unicode.org as a standards body and central authority in deciding which characters are referenced by which code points
- the implementation of the CSS3
@font-facerule in web browsers
- support for the OpenType font standard in web browsers
(Full disclosure: as a consultant for Google, I worked on quality control for many of these new fonts. But the views expressed here are strictly my own.)
The need for wider language support alone is enough to drive webfonts unstoppably forward. Sure, if you’re a native speaker of English working blissfully on a Macbook in a London pub and the year is 1886 and the sun never sets on your empire, by all means, stick with system fonts. But the truth is this: you can’t and won’t be able to count on the local operating system of every device to support all of the languages demanded by a truly worldwide web.
But enough. You don’t need a weatherman to know that a protest by one contrarian web designer won’t change the way the wind blows. Besides, websites are team efforts built and improved by collections of people. There are built-in institutional barriers that can delay and sometimes defeat the adoption of a new technology. It’s a thing.
So, let’s take a look at where the adoption of webfonts across the industry stands today, and call it a wrap.
Patterns of adoption#section7
Using webfonts means accepting that the typographic look-and-feel of a site is no longer in the hands of the makers of operating systems—it’s in the hands of those creating the site. Perhaps those hands are yours. Now, some may take on these new responsibilities eagerly; others may not. Those with a background in graphic design who miss the freedom to choose from a variety of typefaces will probably push hard for the change, while those who lack that background, or who champion performance over style, may urge caution.
Typography is a big deal. It’s branding. It’s identity. The desire to stand out visually is as powerful on the web as it is in any other medium—if not more powerful. And so far, along with a reflexive impulse simply to escape the sameness imposed by web-safe fonts, such motivations have proven strong enough to overcome the inertia and “if it ain’t broke, don’t fix it” attitude infusing many organizations.
But no matter how great the desire to change, internal politics, cost analysis, budgeting, and scheduling all take time.
Technical innovations don’t diffuse randomly. There’s a pattern to adoption, like ripples in a pond after a stone is thrown in. Below is a graph of a diffusion curve—the pattern of the ripples—with a red dot placed on the yellow line showing the point where webfonts have progressed with usage at 60 percent of the potential market:
As you can see, the adoption rate is about a third of the way into the group of users labeled “late majority.” We’re not quite at the point where everybody assumes that everybody is using webfonts everywhere, but we are at the point where those who aren’t are wondering: Why aren’t we?
There’s no going back, and there’s no staying behind.
Are you ready to roll?