A First Date with TypeKit
author: tom
Several weeks ago, I found myself in a friendly debate with a co-worker over the handling and future of fonts through the web browser. Hours later, a TypeKit invite landed in my inbox; how coincidental.
Vegetarian Chicken
To break down what is happening with TypeKit, Jonathan Snook has a nice article that articulates the licensing limitation and techniques needed for successful @font-face embedding – TTF/OTF, EOT, and SVG. These are the basic tenets of utilizing @font-face from a technical standpoint, minus TypeKit’s JavaScript for legal embedding and SVG.
@font-face {
font-family: 'GothicCustom';
src: url("LeagueGothic.eot");
src: local('League Gothic'),
url("LeagueGothic.svg#lg") format('svg'),
url("LeagueGothic.otf") format('opentype');
}
He also encapsulates the fact that font issues break down to essentially two buckets, browser compatibility and licensing. This is a huge differentiator for TypeKit – all fonts based on your subscription level are properly licensed. This does not come without a caveat unfortunately. Rather than choosing from fonts common to designers such as Frutiger, Futrura, Univers, etc – TypeKit presents a list of imitations. And thus I suddenly felt like I was looking at a Chinese buffet dish labeled as “chicken” even though it’s not – you’re not fooling me!
Rationale: Who cares if it’s not real chicken, Chinese “chicken” tofu kind of tastes and feels like real chicken so stop complaining – it’s healthy for you. Translation: TypeKit font families aren’t quite what you are used to but most of them are close enough – and they are fully licensed, everyone is happy.
The Vegetarian Dies of Malnutrition
If you are not a fan of JavaScript and are just interested in a purist CSS only solution, you should really leave now – yes, TypeKit relies on JavaScript just as most of its competitors. Comparing apples to apples (in this case TypeKit vs sIFR), TypeKit’s JavaScript footprint is a bit smaller than sIFR’s ~10k compared to sIFR’s ~20k. But wait – how exactly is the font getting inserted into the page – it’s not like we are using a system font that can just be accessed at the OS level? As it turns out, each font in TypeKit is upwards of 100k and in my small use case, for 2 fonts in my kit, I was hitting 240k. Now you can trim this down depending on the font you choose and exact character sets, however, this was what the TypeKit editor defaulted to for my demo site’s needs.
Comparing apples to apples again, in my small use case for 2 separate fonts via a single SWF file – oh and these were my EXACT brand fonts, not imitations – I was hitting about 50k. This could certainly explain the load and render delay many (not just myself) have been experiencing with TypeKit. Another contributor to render time could be the fact that TypeKit requires their script to load in the <head>. This is contradictory to Yahoo’s optimization guidelines and progressive loading – it forces that 250k to be rendered before anything else on page can be rendered. Did I mention TypeKit costs money too?
File size and loading optimization aside, browser compatibility – the overriding limiting factor we usually face is also an interesting study. Obviously there is always a significant margin in these statistics, but for reference here is the current browser usage share and Flash penetration:
In some of my personal findings with TypeKit, Chrome is a no-go, along with earlier versions of Firefox, IE, Opera, and Safari and sporadic behavior in all of the above. And I’m not the only one. Again TypeKit is still in beta, so they get a little bit of a freebie here, but the fact remains that @font-face has remained somewhat elusive for so long, for so many reasons, and to think that it is solved right now would be a bit naïve. By comparison, Flash replacement is somewhat bulletproof these days as Flash has become somewhat ubiquitous.
Give Me My Meat and Potatoes
Indeed, it is hard to argue the need for better handling of non-standard web fonts. My personal philosophy around non-standard web fonts has always been holistic in nature – sIFR is good, but it still doesn’t solve the problem fully and neither does Cufon for that matter – so I often err on the side of creative use of standard web fonts. TypeKit is definitely a progressive effort to solve the problem of non-standard fonts in the browser.
Maybe I’ve been abused by bad technology hacks in the past, but I think the real issue goes deeper than our siloed world of web browsers and markup. Which brings me to a conclusion of why we have been trying to implement non-standard web fonts in the first place: designers want finite control. And this is the very reason why there is such a difference in standards between OS’s standard fonts and more importantly how they are rendered – Apple typically sides with the font designer and Microsoft does not.
The difference originates from Apple’s legacy in desktop publishing and graphic design. The nice thing about the Apple algorithm is that you can lay out a page of text for print, and on screen, you get a nice approximation of the finished product. This is especially significant when you consider how dark a block of text looks. Microsoft’s mechanism of hammering fonts into pixels means that they don’t really mind using thinner lines to eliminate blurry edges, even though this makes the entire paragraph lighter than it would be in print.
The advantage of Microsoft’s method is that it works better for on-screen reading. Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that’s comfortable to read is more important than the typeface designer’s idea of how light or dark an entire block of text should feel. Indeed Microsoft actually designed font faces for on-screen reading, like Georgia and Verdana, around the pixel boundaries; these are beautiful on screen but don’t have much character in print.
Joel Spolsky – Font smoothing, anti-aliasing, and sub-pixel rendering
Rather than standardizing on one solution for the masses, OS manufactures, browser developers, the W3C, and [you name it standards body here] keep giving us lame excuses instead of real options. And until then we are left with 80% complete excuses for using non-standard web fonts – sIFR, Cufon, and I’m sure TypeKit will not be the last.
Nov 3 2009
5 Responses
spoken by: Jeffrey Veen spoken by: tom spoken by: Tweets that mention A First Date with TypeKit | Tom Lauck's Deseloper.org -- Topsy.com spoken by: Rina Slaugenhaupt spoken by: RichardLeave a Reply