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)#section2
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?
Wrong.
In a post called “Webfonts”, web designer Adam Morse says we should all just say no to webfonts and insists that system fonts are a better choice.
What?
Just say no#section3
Morse writes:
There are a lot of arguments around why you should use webfonts. In none of those arguments, have I heard about a single problem being solved for users.
He goes on:
Over the last three years I have participated in a number of testing sessions. In that time I never heard a user complain about:
- the use of system fonts in a design.
- a website having the same typeface as another site.
- a page using system fonts that loaded too quickly.
- a site NOT using web fonts.
On the flip side I:
- observed users abandon a website because the page was loading slowly.
- heard people complain about the dreaded flash of unstyled text.
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:
Most of the time, front-line developers don’t get to spend time looking at the big picture…Even folks who are tasked with keeping track of the big trends can get sidetracked…It seems like people don’t really think about how fundamentally the Web has changed.
But then, also, maybe there’s some truth to what Morse is saying.
Ouch.
J’accuse!#section4
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.
The CSS 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:
- Chrome and Firefox have a 3 second timeout after which the text is shown with the fallback font. Eventually, a swap occurs: the text is re-rendered with the intended font once it becomes available.
- Internet Explorer has a 0 second timeout which results in immediate text rendering: if the requested font is not yet available, fallback is used, and text is rerendered later once the requested font becomes available.
- Safari has no timeout behavior (or at least nothing beyond a baseline network timeout)
He continues:
While these default behaviors are reasonable, they’re unfortunately inconsistent across browsers. Worse, no single approach is sufficient to cover the range of use cases required by modern user-experience–and performance–conscious applications.
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#section5
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.
More help was on the way: WOFF webfont compression (and the new and improved WOFF2); finer control over loading using JavaScript; speedier delivery of assets using content delivery networks (CDNs), and emphasis on best practices like setting cache headers so that on initial download, webfonts are stored locally in the cache to avoid delay due to network latency on subsequent visits. Browsers improved, too—they started supporting a greater number of simultaneous connections for faster, parallel downloading of linked assets, and a newer and faster protocol (HTTP 2.0).
The main objection to webfonts has always been the prospect of a fitful user experience on page load, particularly on a first visit, when the browser hasn’t yet had the opportunity to locally cache any of the site’s assets and localStorage can’t yet come into play, as it does in some of the JavaScript polyfills for the controlled loading of webfonts. First, there’s a delay caused by the time it takes the network to deliver the webfont and that, in turn, causes a so-called flash of unstyled content (FOUT) as the browser paints the page with a fallback system font and then repaints the page when the webfont arrives. Now, without getting into the many possible causes for network latency, the simple and only solution for this scenario is a faster network connection.
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#section6
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.
Let’s call it “regressive insistence.” (How’s that for a euphemism?) It’s simple: you pull the hammer labeled “JavaScript” from your toolkit and bang at the browser with it until webfonts work. And with only a little banging, they work quite well. In fact, a particular set of hammer strokes —so to speak—has been standardized in the CSS Font Loading API.
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.
As Jason Pamental writes in Responsive Typography:
The answer isn’t, as some developers have called for, to not use web fonts at all, but rather to do our job and control the process with the tools we have at hand. Type is simply too important a design element to give up just because we’re lazy.
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 appears that he argues we should use a “web-safe” or a system font because they’re more predictable. However, I would argue that there’s no such thing as a “web-safe” font.
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#section7
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#section8
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?
Minor niggle:
httparchive.org only surveys the Top 500,000 Alexa websites (http://httparchive.org/trends.php)
You can get nice SVGs of the charts from http://mamasnewbag.org (when I get round to updating the database). 😉
@Charlie Clark
http://fc-united.de/
Thanks for the info on the number of urls httparchive.org actually crawls. Their site is somewhat confusing on that point.
On an FAQ page, it says this:
How is the list of URLs generated?
The list of URLs is based on the Alexa Top 1,000,000 Sites (zip). Use the HTTP Archive URLs page to see the list of the top 10,000 URLs used in the most recent crawl.
(So which is it, one million or ten thousand?)
And then, on the Trends page, in the Number of Urls chart, it shows a little under a half million, as you point out.
And I’d like to add that httparchive.org doesn’t crawl entire sites, just the pages correponding to the list of URLS from Alexa.
Thank you Charlie, and thanks for the tip about mamasnewbag.org – I’ll definitely check it out.
@Richard Fink for some reason you’ve included the URL of one of my private sites (I’ve probably configured Apache incorrectly). http://www.mamasnewbag.org/
This uses the data from httparchive.org but runs on a different backend and uses the more recent Google API for charts. Will be updating website reports to take advantage of the fact that now all the websites are measured as desktop and mobile websites: webfonts are an even bigger problem on mobile devices!
@Richard Thanks for sharing your thoughts on this. I learned a lot from your article. Was wondering if you have any citations where I say ‘we should all just say no to webfonts’ or that I think ‘that sticking with tried-and-true system fonts is best for all concerned’? I couldn’t find where I say either of those statements in my talks or writing, but curious if I missed something.
I enjoyed this article and it was a useful update on the state of web fonts. That said, at times I thought the article was too insistent that popular == good, which is a line of argument I’m surprised to see in this space.
That said, if popularity is an important metric for you, it’s worth acknowledging that the recent version of WordPress has removed web fonts from the admin area.
Anyways, thanks again for the article . Enjoyed it.
I think i always had a problem with webfonts regarding their ugly rendering in windows based internet explorer machine. And i don’t see real improvement on that. Any thought on this ? And a way to a handle it better ?
Even recently, popular Google Font have real display issues in microsoft browsers (kerning / aliasing)…
Am I alone with that ?
@Scott Fenell If the article came off as saying, to you, that popular == good, then, as a writer, I presume myself guilty until proven otherwise, of giving you the wrong impression.
Webfonts have become popular and are on their way to being omnipresent because if the web is to take its place as a publishing technology in every sense equal to print technology, ya gotta be able to use the font that you’re fond of and not just the font at hand. (h/t to Yip Harburg for that.)
Also, to some extent, human progress depends upon the new and improved becoming more popular than the old and obsolete and so it’s fair to say that, if the newly popular has become popular for good reason, which is usual, then certainly it can be said that popular == probably good.
Now, if we’re talking about the look of the font, that’s a different story. @font-face can be used for good or evil like every other tool.
But know this: webfonts aren’t a fad. There’s no need for a bandwagon. In hindsight, it’s something that, when you stop and think about it, had to happen and it’s happening now.
@Benoit Mercusot
Who wrote:
“I think i always had a problem with webfonts regarding their ugly rendering in windows based internet explorer machine. And i don’t see real improvement on that. Any thought on this ? And a way to a handle it better ?
Even recently, popular Google Font have real display issues in microsoft browsers (kerning / aliasing)…
Am I alone with that ?”
I see problems in all browsers and at all kinds of sites. I’m constantly shocked by the poor rendering of some fonts I see on sites with otherwise competent design.
I see font weights being used that are so light the text is nearly invisible. On a Mac, they might look ok, but on Windows, they ghost out.
I see fonts with obvious distortions in stroke weight from size to size due to poor TrueType hinting.
Unfortunately, fonts as technical things, are still much too much of a mysterious black box to most designers.
There’s a long way to go, Benoit.
Writing as someone who has and will continue to work on these quality control issues and is trying to speed up and start writing more often and more specifically about what designers need to know to deploy webfonts successfully – I know it’s lame to say – but “we’re workin’ on it”.
We really are.
BTW – if you have any particular issues you want feedback about, feel free to ping me in one way or another. Either on FB or @FontFridayTweet, or however.
@mrmrs
You’re pissed off, right?
Don’t be.
Two things:
1) I don’t believe I misrepresented the substance of what you wrote in any way. If you feel I did, come back here and just set the record straight or ping me and we’ll do it privately.
2) Your post had a domino effect, obviously, and that’s pretty powerful. Whether you were right or wrong or somewhere in between is nearly irrelevant.
You RAISED THE RIGHT QUESTIONS and I’m grateful to you for that.
Besides, I’m sure your opinions are probably way more sophisticated than could fit into a small post like that, and maybe you were being contrarian just for being contrary’s sake.
How much less fun would the web be if you can’t write something you only half-believe just to get a rise out of somebody every once in awhile, eh?
😉
After reading this, I can’t help but think of Apple’s decision to ditch the headphone jack in the new iPhone 7. People are complaining about it but it’s just technology moving forward. There are still problems with webfonts but the problems are diminishing every day. This is clearly the direction the web is headed in.
@Benoit Mercusot – One other thing. I wanted to mention that fellow ALA author Jeremiah Shoaf publishes typewolf.com which has a curated list of screenshots showing webfonts in action all over the web, plus downloadable fonts, and a terrific “Definitive Guide To Webfonts”. So, at the very least, Jeremiah has eyeballed all of the stuff Typewolf features and while the inspection might not go deep, at least nothing jumped out at him as funky. (I am not his agent.)
I am curious if those who advocate abandoning webfonts have an opinion on image size and image compression, which generally have a much greater impact on page weight than fonts have.
I would not use Google Fonts to judge webfont quality in general. Until very recently, their design and hinting standards have been quite low (as might be expected from a free product). Instead, have a look at foundries who put concerted effort into their screen fonts (like Font Bureau, Hoefler & Co., Frere-Jones, Commercial Type, and FontFont) to determine whether webfont performance on Windows can live up to the standard set by Microsoft’s Core Fonts for the Web. Most of these suppliers provide screenshots from a variety of browser/OS environments so you know what you’re getting, even if you’re designing on a Mac. In most cases, you get what you pay for.
Just want to mention that Jeremiah Shoaf’s book “The Definitive Guide to Free Fonts” is worth every penny and more.
@Richard not pissed off, just disappointed in your integrity as a writer. You are misleading people to believe I said things I didn’t. As a member of a community, this doesn’t seem like the way to foster discourse responsibly. I expected more professionalism and courtesy from someone like yourself.
@Richard thanks for sharing ressources. That typewolf.com website seems to be a great place to learn 🙂
@Stephen Coles
“I am curious if those who advocate abandoning webfonts have an opinion on image size and image compression, which generally have a much greater impact on page weight than fonts have.”
I’m assuming the point you’re driving at is, if you’re going to be critical of file sizes that take up a lot of bandwidth, why pick on webfonts that, as a collection of vector images, give you a lot more bang for the download buck than bitmap images – hence the popularity of Icon Fonts – and skip criticism of bloat caused by image files?
First, anybody serious about page speed needs to be concerned with both.
Second, SVG is now quite well supported in browsers and is sure to replace many, many bitmap images with a vector equivalents that, unlike bitmaps, scale beautifully, have smaller file sizes, can be used with the same versatility as images such as with the CSS background-image property. SVG images can also be combined in sprites so that many SVG images are downloaded all at once, rather than one at a time. Dammit Jim, it took long enough, but SVG is finally viable. It’s the future.
Third, and unfortunately, images to webfonts is not an apples to apples comparison because, while images can cause bloat, webfonts not only can cause bloat but can also hold up the rendering of the page and stop the browser from continuing to download other assets. In other words, webfonts can gum up the works and delay page display in ways that image files don’t.
It’s the reason for my criticism that browser makers and the W3C have been slow to attack this problem. (See the J’accuse! section of the article.)
NOTE: Since this article was written there’s been a fundamental change in Safari’s behavior. Safari now acts like Firefox and Chrome by obeying a 3 second timeout – meaning that, if the webfont hasn’t downloaded by the end of three seconds, the browser paints the page with the fallback font and then repaints when the webfont is finished downloading.
These remarks don’t really answer your question, Stephen, but I wanted to put the question into perspective in light of current trends.
I see another commenter heralding Hoefler as a proper quality typeface solution (usually true), but their web-delivery service is so disappointing—no performance-reliant site should ever use their delivery platform. They basically give you two options for implementation (and they really only recommend the first):
A. Delay the rendering of CSSDOM until their engine points to the correct font (this is a call out to their server for logic, but the font is hosted on your server – which is a bit frustrating)
B. Add your own JS and delay their delivery platform (so, a local script to delay an external script to point to a font stored on your webserver)
Which ties you to:
A. Get penalized by Google’s algorithms for render-blocking
or
B. Penalize your users with FOIT/FOUT (good luck ever using their condensed fonts with FOUT)
With these considerations in mind, a large scale performance-dependent website (ecommerce in my experience) should not use a JS-based font delivery service. We’ve seen multiple large-scale retailers claim that any delay in rendering will impact bounce rate and sales (Amazon is known for claiming 100ms latency = 1% sales loss). At scale that can mean millions of dollars in sales lost to font rendering.
You can’t rely on operating systems to supply a system font reliably, but in a similar vein can you rely on ISPs and third-parties to reliably fulfill external calls that block text rendering?
If you’re relying on performance don’t even bother pulling that JS hammer out of the drawer. Storing font files on your server and delivering via @font-face is the only current solution that can deliver in terms of performance and user experience (which as the author pointed out above, is still lacking in its own right).
Sorry about beating a dead-horse a bit, but I’m really frustrated about being unable to use Hoefler typeface on the web. So close, yet so far away.
Great read on web fonts (Didn’t know of the huge story behind it).
@richard
Just because lots of sites use webfonts it doesn’t make them right (after all look at how many sites used Flash?)
In my experience (I do site performance full time) fonts are the blocker to early rendering on many sites and given the choice between the font a site chose and seeing the content you can guess which I choose.
More bandwidth doesn’t really solve the problem
– they’re discovered late i.e. when the render tree is built by which time the browser has the text and is just waiting for the damn font to be able to render it
– we’re increasingly using mobile devices which use higher latency / unreliable network connections so getting the font is slow if it happens at all
The font display property will help make things more robust but it was proposed over a year ago and only one browser supports it…
@andydavies
Here’s the bottom line:
The reason why I titled the two pieces I’ve written so far about webfonts for AListApart, “Web Fonts At The Crossing” and this one, “Webfonts On The Prairie” is because I’ve always seen webfonts as a mass movement similar to other mass movements like the one touted as “manifest destiny” in American history. Manifest destiny was the idea that European settlers and their descendants were, for good or ill, destined to occupy the entire North American continent, from sea to shining sea.
And so far, as fonts on the web have edged out further and further, site after site it looks more and more like my initial instinct about webfonts was correct.
As a quick aside – I was recently reading the Master’s Thesis that Google Font’s Dave Crossland wrote some years ago while studying type design at the University Of Reading. Early on, it mentions thinker and theorist of social psychology Eric Hoffer’s contention that mass movements – usually political, but other kinds as well – arise out of a widespread feeling of frustration. (From Hoffer’s book “The True Believer: Thoughts On The Nature Of Mass Movements”, 1951.)
It runs like this: a whole bunch of people have been frustrated about something for a long time. Finally, path away from that frustration appears navigable, and a mass movement is born.
In that vein, webfonts are a mass movement within the design community. And every movement has its doctrine and it has its fanatics. There are web designers – good ones – who are perfectly aware that webfonts will adversely affect the performance of their pages, but frankly they don’t give a damn. They are perfectly willing to sacrifice some users experience in exchange for not feeling frustrated anymore and advancing the cause. Also, some designers see the performance issues as somebody else’s problem to solve, not theirs.
If they can use webfonts, they are going to use them. Period. It’s a callous attitude, but I’ve seen it firsthand.
Once a mass movement gets going, it marches forward ruthlessly and relentlessly. (Eric Hoffer suggests that at least some fanaticism is a necessary catalyst for bringing about abrupt and radical change.)
It’s an attitude summed up by the old expression, “You want to make an omelet? Well then you’ve got to break some eggs!”
Webfonts are not a passing fad, they are not a niche technology like Flash, they are now a part of the fabric of the web. And, very importantly, unlike Flash, @font-face is not proprietary, it’s a standards-based solution and that makes all the difference in the world.
Yesterday, at the ATypi Conference in Warsaw, what amounts to a peace treaty between Adobe, Microsoft, Google, and Apple was announced in the form of agreement on the new OpenType 1.8 standard. This marks a level of cooperation that’s unprecedented. And a lot of the change is driven by having to move font data more efficiently across the network – webfonts as destiny, once again.
I acknowledge here and in the article, certainly, that much of what you’re complaining about is either totally or partially true.
Forgive me for not evaluating each point you touch upon, individually.
Perhaps a “Webfonts: Pros and Cons” article should be written to deal with it all most efficiently.
But the bottom line is that there is nothing inherently flawed about webfonts themselves. A font on a server is an asset just like any other so there is no reason why the problems you outline can’t be remedied.
I’m a former Certified Systems Engineer and I understand latency and bandwidth issues same as you. Have those problems not lessened over the years?
Of course they have.
Get used to webfonts, learn to like them, have some of them over for dinner.
A mass movement isn’t stopping for you, or for me, or for anybody. Find a way to make webfonts work as best you can today, and then go forward knowing that they will work even better tomorrow.
One point I think you have entirely backwards is the notion that webfonts are any help for extended unicode support. You have to ask, what is more likely? That a user will have their preferred language configured on their device with a font that works for them, or that any webfont you decide they ought to use will support their native language?
Obviously the user will have a system font that supports their language. Chances are, the webfont you picked out before they visited the site, perhaps even before the characters they required were included in unicode will not support their language. System fonts are the clear winner for extended language support.
@garnet
I grew up in Brooklyn, New York and when I was about eight years old I was sent for religious indoctrination to a local after-school program for four days a week – five if you count Sabbath services on Saturday morning. Class was held in an Orthodox Jewish synagogue where my folks were active members.
Most of the years I went there I had a teacher named Mr. Jacobowitz. (To this day, I don’t know his first name.) Mr. Jacobowitz did something that no teacher I’ve ever had before or since did: he gave extra credit for asking an especially good question.
He would actually stop class for a moment, compliment you and make note of it on your grading card.
Because of Mr. Jacobowitz, I got the message early in life that asking the right question is more important than having the right answer.
So my answer to you is: excellent question!
If I was giving out a prize in honor of Mr. Jacobowitz for best question asked in response to an A List Apart article, yours would win.
(A List Apart staff, take note.)
Of course, if you suspect this little reminiscence is just me attempting an amusing dodge because I don’t have solid, definitive information to offer you – uh, you’re mostly right. Hah! 😉
But bear with me. The most prevalent feedback I’ve gotten from this article is that designers want to know more about internationalization and trans-cultural fonts. (Or do you like the word ‘multi-cultural fonts’ better? There are reasons I don’t like the phrase ‘multi-script fonts’ and I’m trying to find better.)
Anyway, I am working on a follow-up article that tries to shed some light on exactly the points made in your question.
Stay tuned.
Some concerns:
1) Visitor may find your particular font choice, e.g., Garamond in my case, hard to read
2) Visitor may not have an unlimited mobile plan, so you are making them pay for your vanity
3) Supposedly page abandonment rates go up after even a couple of seconds
Actually, I just encountered a site using Montserrat and had to zoom in 5 or 6 times before it was comfortable and cartoonishly large for me to read. I only have to zoom in once or twice to read A List Apart’s Times (something I like in print but not onscreen).
Actually, Raleway, and I wound up inspecting the element and replacing with Arial. Yup, 275% zoom to read Raleway comfortably, 125%-150% zoom to read Arial comfortably.
Please think about this when choosing your wonderful alternate font.
I, mostly use system fonts. It’s good to see my site on iOS devices using apple’s system fonts :).