The Landscape of Web Typography

Preface

This post was originally drafted as a talk for CSSConf, which I sadly had to back out of speaking at. In lieu of the talk itself, I thought I’d instead publish a torrent of thoughts on the titled subject. And let’s not ignore the fact that this formatting may in fact be better, given its proximity to the subject at hand. This will be read on a vast number of browsers, in people’s hands and at their desks, and in anywhere between a few months and a few years, many of the facts pointed out herein will be false or irrelevant. It’s an exciting and frustrating time to be enthusiastic about typography on the web. Let’s dig in.

Introduction

Hi. For those of you who don’t know me, I’m Daniel. Those who do know me probably know me because of Animate.css. Believe it or not, I do work on things besides CSS animations. Most of that work is done at Dropbox, where I’m a Designer. I also maintain Ragged Write, a blog about typography (though I’m not very good at that—type news is slow); Onword, a place to write; and Just My Type, a collection of web font pairings. I’ve also written about web type for Typecast a few times. In case you can’t yet tell, I’m kind of into typography.

This obsession, combined with my curiosity with and attraction to the web, naturally led me to the topic for my talk today. Being a typoholic on the web is hard; as with layouts, we have the unpredictable nature of the web and its various browsers dilly-dallying with our typographic styles, with discrepancies both small and large across any number of platforms, devices, and screens. But things have improved in recent years, and continue to do so daily. Here, I thought it might be nice or interesting or scary to take a stock-check of typography on the web as it exists today. Let’s go through this together.

The State of The Union

Any Graphic Designers should probably get all of their laughter out of the way while they can. The cold, hard truth is; typography on the web stinks. Let’s take a look at today’s workflow. We’re going to design a website.

Unless I want to use Verdana, Georgia, Times New Roman, or Arial, my type choices are pretty much restricted to those available through a number of services. There’s Typekit, which is owned by Adobe and, well, smells like Adobe; Fontdeck, which is admittedly not exactly a painless service due to it’s pay-per-font restrictions which only work for corporations who are unlikely to flex on their typographic choices; Google Fonts, which—though comprehensive—is severely lacking in both features and quality; H&Co.’s Cloud.Typography¹, which has perhaps the best catalogue, though is out of many people’s budget and comes with a performance penalty (500kb is about as small as you’ll get for a good pairing from H&Co.); Adobe web fonts, which is basically just Typekit/Google Fonts on Adoberoids; a multitude of other options which are either too expensive or have far too high technical constraints and payloads; and, last but not least, self-hosting. Don’t even get me started on the complexities and caveats of self-hosting.

That’s a lot of choices. Are we having fun yet?

Let’s go with Typekit. It’s (relatively speaking) cheap, easy to set up, and has limited control (which means limited opportunities for screw-ups.) Typekit has a wonderful catalogue of typefaces from a vast array of foundries, two of which you’re seeing here now—Leitura News and Franklin Gothic URW.

Once you pick your typefaces, you add them to a “kit.” Basically Typekit-speak for a project. Then, you choose your weights, language support, and domain(s), and you’re ready to go. Typekit gives you a code snippet to put in your site so that you get your fonts. But it’s a JavaScript snippet, not a CSS link.

Even after this debacle, what are we left with? A ghost of a typeface; type stripped of most of its OpenType features—things like true small caps, case-sensitive punctuation, and ligatures—unless you opt for performance-degrading delivery of fully-loaded font files².

I’m dramatising a little here, but you get the picture. Things aren’t great. But they’re a damn sight better than they were just a few years ago. When I was first dabbling in web design, if I wanted to use a typeface that wasn’t “web safe,” it meant one of two things: I’d be showing the user a picture (literally an <img> in most cases) of that typeface, or I’d be using Cufón, which in its prime used Flash (back when it was still Shockwave Flash) to display fonts. Just thinking about that makes me weary.

Doing Our Best With What We’ve Got

Ok, so things are grim, but they used to be a lot worse. What can we actually do? As it turns out, quite a lot. I told you I was dramatising earlier.

At the time of writing, Google Chrome is just about the only browser with which you’ll be able to see it, but there are actually a number of great typographic features in this post. If I were to talk for a moment about, say, CSS and HTML, you’ll notice that Leitura News’ true small caps are coming into play. If I spit out a number or a date like 18th February 1991³, you’ll see old-style figures bobbing up and down along the baseline as opposed to Leitura’s default lining figures, which sit neatly inline together.

This is the tip of the iceberg. In other typefaces, we could get alternates, swashes, contextual ligatures, a spattering of numerical characters, and much more. These are called OpenType features, and they’re what really takes a typeface above and beyond vanilla typesetting. If I were even a little bit cooler, this is where I’d say “These aren’t your mother’s fonts, guys.”

These features have been around for a long time in digital design. Adobe’s Creative Suite has some pretty nice tools for working with OpenType features, particularly InDesign. The fact that we have access to native OpenType features on the web is really exciting. I’m not going to go into too much technical detail, but Elliot Jay Stocks wrote up a really great overview.

The Bad News

There is some bad news, sadly. Like I mentioned before, the only browser with semi-comprehensive support for native OpenType features today is Google Chrome. You’d think that Apple’s Safari would be leading the way here, having a staunch history in the development of modern type rendering⁴, but Safari’s adoption of CSS font properties beyond those specified in CSS 2.0 has been slow.

Speculation tells me adoption of these features is slow for a good reason—performance. Everyone wants a fast web, but that can only really happen if the way that pages and web apps render is easily predictable. The problem with many OpenType features is that they can have a significant and unpredictable effect on the appearance of type. Even simple ligatures—the optical adjustments to sets or pairs of letters with conflicting letterforms such as “fi” and “fl”—can quite significantly change the layout of text. On top of all its other duties, the browser now has to deal with text that doesn’t necessarily look the same as it expected, and what that means for text that’s editable or selectable⁵.

I think we can all agree that it’s reasonable for us to calm down and remain patient for browser implementations of OpenType features. Maybe.

Another interesting part of this problem to note is H&Co.’s solution to it. For their Cloud.Typography service, they allow users deep-level controls over the fonts that are delivered. They surface toggles for small caps, titling versus old-style figures, ligatures, language sets, alternates, and all sorts. What this means is that you can effectively duplicate fonts that exclusively carry a certain OpenType feature (say, for instance, you want Whitney with small caps, Cloud.Typography would let your site receive two font files: Whitney, and Whitney all small-caps). The result is a total font payload that is significantly larger in download size, but extremely flexible. Even for browsers lacking support for true small caps, you could have HTML classes that use the font that’s all small caps instead.

Had I written about this just a few years ago, there would have been a much stronger fire-and-brimstone undertone. Thankfully, I think we’re at the epicentre of a typographic revolution on the web. We’ve been wallowing in the vanilla typesetting mud for quite some time, and there’s a lot of exciting stuff ahead of us.

Personally, I’m excited for a few things in particular: browser vendors are working on implementing more typographic features, little by little; devices and internet speeds are getting faster, meaning even our heavyweight font files will get to more users in less time; and the services we entrust to deliver great web fonts are constantly improving, making performance optimisations as well as designing or cataloguing more comprehensive typefaces.

Sure, things aren’t great. But we’re well through the worst of it. Happy typesetting.