MikePadgett.com

Typekit: when will web fonts flow freely?

Proper font embedding in a browser is long overdue. We’ve had to put up with the same old Arial, Verdana, Georgia, Helvetica, Times New Roman for years.

Now that browsers have to some extent caught up with the rest of us, thanks in no small part to a bit of healthy competition, Typekit has finally answered the call: you’ll soon be able to choose what fonts drive your website.

Everyone’s favourite glue

We’ve had sIFR, we’ve had MIR and we’ve had RIR. We’ve probably had enough.

None of these solutions proved to be ideal, but how often is anything ever ideal on the client side?

Well, let’s take a look at Typekit. At the time of writing, there isn’t too much to go on, but what we do know is this:

1. Typekit’s solution uses (quite a lot of) Javascript
2. The solution ‘downloads’ a font feed from a predetermined location
3. A ‘modern’ browser will interpret CSS @font-face correctly and render the desired fonts

So Typekit is merely following in the footsteps of jQuery, Prototype and other JS libraries. It’s about using Javascript as a sort of web glue to make things fit together. However, this time around it’s not being used to cover up for browser naffness.

Typekit will count on consistent support of modern browsers for the @font-face at-rule. This at-rule has actually been around since the CSS 2.0 specification, though a better, verbose description appears in CSS 3.0. An orthodox implementation of the at-rule looks like this:

@font-face {
font-family: "Mike Old Face";
src: url("http://www.mikepadgett.com/fonts/mikefont.otf")
}
/* The .TTF (true type format) will also be supported, as would *any* URL */


Once the font is “instantiated”, it can then be utilised (in Hemingway’s Fiesta sense of the word) normally:

h3 {
font: normal 120% "Mike Old Face", "Times New Roman", Times, serif;
}

Browser support for @font-face is still a bit patchy but things are picking up fast and now the browser people have discovered the joy of automatic updating, we can expect a fairly rapid uptake.

On the bright side, it’ll mean that designers can make more beautiful websites. The dark side is that many other websites are going to get a lot uglier!

But glue can get sticky

Microsoft tried and failed to get their Embedded Open Type solution accepted by the world at large (there wasn’t much of anything ‘open’ about it, of course). Redmond ended up handing it over the W3C as a feeble proposal for CSS 3.0.

One of the itchier reasons for all the fumbling was the issue of proprietary rights to the fonts themselves. This same issue may well cause problems for Typekit, though this time in the reverse sense.

You see, whilst the Typekit solution is likely to appease and perhaps even create uncharacteristic interest from type foundries (it appears to properly respect intellectual property rights), it might not sit well with many designers and even less with developers.

Here’s why:

The story goes that the Typekit script is going to be pretty hefty. It needs to be to do all the processing it would need to do and how long is that going to take? In addition, the font pattern will then also need to be downloaded (some fonts are marvellously chunky themselves).

Next, the matter of the rights. One of the first things I learned about business is that the real value is in contracts rather than sales, especially when you’re selling other people’s products. So it goes without saying that Typekit needs to be a subscription service.

On the one hand, some orgs would sell their chairman to properly and faithfully reproduce their branding online. How on the other, as one commenter suggested, do you now square it with your client that your design will actually attract an ongoing cost? Could this be another opportunity for Open Source or are the foundries on the edge of the precipice into which the music industry has already fallen?