The Font-as-Service

When Johno first asked me to write about Typekit, I jumped at the chance. I'd received a beta invite to try out the service about a week before, but deadlines had got in the way of actually getting round to it. Now I had the perfect excuse to have a proper play, create a test site, and immerse myself in the technology that got the web design community frothing at the mouth when it was announced a couple of months ago.

However, as I started to experiment with Typekit, I realised that the really interesting thing isn't the technology itself: it's what Typekit — and other services in the same vein — mean for the way we experience type on the web. And I'm not talking about it from a user's perspective, where they get to see the end results of using a variety of typefaces, but from the web designer's perspective: the way in which we're going to be using and paying for fonts.

Let's get some of the nitty-gritty out of the way first: if you're unfamiliar with Typekit, there are plenty of blog posts out there that will get you up to speed very quickly. A logical place to start would be the official release announcement on the Typekit blog. Done that? Jolly good. Now you can peruse the various opinion pieces: Andy Clarke offers a very thorough walk-through of the service, and Mike Davidson examines (among other things) the question of Typekit's compatibility reach. Because of these posts (and others, of course), there seems little point in me repeating the content here. However, it's worth noting some of the details, because it's in the details that Typekit differs from the other solutions gradually coming out of the woodwork (more on them in a minute). The biggest detail that detractors seem to be focusing on is that its delivery method relies on Javascript; not for the font display, of course, but for the domain authentication. Naysayers point out, therefore, that no font replacement will happen if Javascript is turned off (although it's debatable how much of a concern this actually is) and it also means that it takes a while for the correct fonts to appear while the Javascript loads; an effect often seen on sites that use sIFR.

There are more drawbacks, too. While testing the service I found it simple but not necessarily straightforward, and although much of this can be attributed to its beta status, there's an important point to consider when using Typekit: you're defining your font stack via its online admin interface — not in your own CSS files. For me, this was the moment I really developed my doubts about the service, since that kind of separation feels very unnatural to me and acts as a major disruption to my workflow. And I won't even go into some of the specificity issues this can arise, except to say that you should ensure the Javascript links appear after your stylesheet links, lest you want to screw up your font stacks completely.

To jump back to Typekit's positive features, however, one of the most overlooked features is that it offers a fall-back for Internet Explorer by serving up an .eot file. Why this is important is because it simultaneously solves two major problems: the availability of multiple typefaces and an integrated delivery method that copes with cross-browser (in)compatibility. Briefly put, it means @font-face is more readily available on IE than it has ever been before because we designers no longer need to worry about all of the fiddly workarounds. This is great news for everyone.

But what about the Typekit alternatives? There are some to get very excited about. Take Typotheque's bespoke solution, for instance. The foundry have released their own alternative to Typekit and Andy Clarke has a thorough write up of that, too. One key difference is that the authentication is done via PHP instead of Javascript, which is sure to appease those who've criticised Typekit on that point. But let's not forget that this is a foundry-specific solution, and I agree with Andy that it's sure to pave the way for other foundries to do the same; it makes a lot of sense (to them) to create their own delivery solutions and maintain control, but it's possibly not the best solution for web designers who have to jump between a variety of systems and pricing models. Wouldn't a standardised system be better? Haven't the last few years of web design practice taught us that unification far outweighs the benefits of proprietary solutions?

Of course, it takes a while to reach one unified model and firstly there's the small matter of fighting it out in the web design community's playground. The most successful model will be the one with the biggest support from the community (and funding), and ideally it'll be one that supports multiple foundries. So let's consider Fontdeck: another multi-foundry solution, the development of which the Typekit guys will no doubt be watching with eagle eyes. Little is currently known of this mysterious creature, but the really exciting stuff, in my opinion, is the people behind it. Spearheaded by Jon Tan and Richard Rutter — and behind them the funding and support of Clearleft and OmniTI — it's hard to imagine how this could go wrong from people who have already done so much for bringing solid typographical learning closer to the web design masses. Unlike Typekit, and similarly to Typotheque's service, authentication will not be done with Javascript, and the word on the grapevine is that we'll be able to work with CSS in a way that's closer to our regular workflow. If this means something like putting a Fontdeck-generated font stack directly into our own stylesheet, then this, for me, will be a very major advantage.

Rumour has it that the Fontdeck team are also considering free support for rare script typefaces, providing a way of getting these lesser-used languages on the web, where currently they are invisible. It's a noble cause and a great example of why proper typography on the web is more important than just pleasing the tastes of us poncey designers.

With Clearleft handling the UI of Fontdeck, we know it'll look great and have a strong focus on usability. With OmniTI handling the security, we know it'll be as tight as a safe. The company's track-record in online security is flawless, and with reliable sources claiming that Typekit's security has already been hacked with relative ease, it's natural that foundries will be more interested in signing up with a provider that can guarantee the safety of their fonts.

And make no mistake: this is what it really comes down to. A very large part of @font-face's painfully slow adoption has been down to the font foundries and their concerns over font piracy, and rightfully so. Microsoft's EOT format in its current state is far from ideal, but because of its potential to offer DRM, it's the format that foundries have been happy to support, albeit half-heartedly. Now, with services like Typekit and Fontdeck, foundries finally have a reason to embrace type on the web: to open their product to a whole new audience without fear of their typefaces being stolen by anyone adept enough to click 'view source'. Unfortunately, though, the pricing structure of these new services is still a mystery. With Typekit already in public beta, it's likely that we'll find out sooner about its price plans than Fontdeck's, but right now all we can do is speculate. Undoubtedly the various services will price themselves competitively, but there are so many concerns that go way beyond the service itself: ultimately, with large foundries' support being such a huge factor in the success of any given service, the price has got to be right for the foundries, not just the service providers or consumers.

And it's not just a case of deciding on a figure, either. The choices of pricing models are potentially endless. Do you charge the user (that is, the web designer) per typeface? Per family? Do you offer a font purchase with an extended license for web use? Do you charge a subscription for a certain amount of service? Do you charge by the quantity of typefaces needed (5 families for $X a month, 10 families for $X a month, etc.)? Do you offer some for free and reserve some weights (or even glyphs, like ligatures) for paid customers? With the amount of questions that need to be answered and the the amount of question-askers who need to be appeased, I wouldn't wish that kind of decision making upon anyone!

But, whatever the details of the exact services that end up being offered, one thing will be true: unlike ever before, where previously we had only purchased a font as a closed, finite, singular product, we are now entering the age of the font-as-service: where the font becomes synonymous with web hosting, mobile data plans, and movie rentals. No longer fixed, fonts will be borrowed, subscribed to, removed, expanded upon, and provided on-the-fly.

In his comment on Mike Davidson's post, Jeff Croft raises the important question about the reliability of the service; not from the view of security I mentioned previously, but from the view of scalability:

When Doug Bowman decides to implement Typekit on Twitter, will Typekit go straight to hell, ruining it for the rest of us? Will we start seeing Typekit-powered sites hanging as we wait for the Javascript bits and font files to load?

With font files being delivered by third-party services, it's a big concern, and another reason I feel reassured that a company like OmniTI will be looking after the infrastructure behind Fontdeck.

I praised Typekit when it was first released, and although we won't know what the best solution will be for quite some time, I stand by my original message: it deserves praise because it was one of the first solutions to a long-standing problem; it got out there and said, 'we can do this,' when most other people were content to sit there and complain about it. But really this isn't about what Typekit does, what Fontdeck does, what the various bespoke foundry solutions do, and how each of them does it better or worse than the other. Nor is it about the specifics of formats like .ttf, .otf, or the recently-proposed .webfont (which was summarised very neatly in Johno's recent post). It's about how service-based models are finally allowing typography to grow up and take its rightful place on the web.

Are we just hacking away to find a solution that satisfies our demands until a workable standard like .webfont or WebOTF is eventually approved and we can all hold hands and sing songs? Probably, yes. But as Mike Davidson said, "the entire world wide web is a hack."

Elliot Jay Stocks is a designer, illustrator, speaker, & author of Sexy Web Design.

@elliotjaystocks