Mike Industries

Last week brought word of a promising new type solution for the web called Typekit. Created by Jeff Veen and the smart folks at Small Batch, Typekit aims to solve the problem of custom typography on the web once and for all. Unlike sIFR, Cufon, and several other stopgaps before it, Typekit does not attempt to hack around the problem, but to solve it in a permanent way, which is exciting.

As a co-inventor of sIFR, I’ve been getting a lot of emails this week asking what I think of this new effort. In evaluating its promise, it’s important to examine the following characteristics, in order of importance: compatibility, functionality, legality, ease of use, and hackiness.

Compatibility

Compatibility is the most important aspect of any new web technology. If your shiny new method only works in 10% of web browsers, it’s nothing more than a proof-of-concept. It is this reality check that keeps me from getting excited about W3C meetings, Internet Explorer extensions, or anything else that doesn’t apply all browsers in the here and now… or at least the right around the corner.

Compatibility was also what pushed sIFR over the top in terms of popularity, working in over 90% of all systems and falling back gracefully in most others. It also came out at a time, 2004, when there wasn’t a whole lot of tolerance for leaving certain browsers behind or having things look ideal in a few browsers and not so ideal in others.

Typekit appears to be doing ok on the compatibility front, targeting current versions of Safari, Chrome, and Opera natively, the next version of Firefox (3.1) natively, and all versions of Internet Explorer via a “backup” EOT solution. Here’s what the browser share landscape looks like today:

• Works in:
  • Internet Explorer: 66.1%
  • Safari: 8.21%
  • Chrome: 1.42%
  • Opera: 0.68%
  • Firefox 3.1 or greater: 0.18%
• Doesn’t work in:
  • Firefox 3.0 or lower: 22.3%
  • Miscellaneous other browsers: 1.11%

So you can see right off the bat that Typekit will work in just over 76% of browsers. Not quite as high as some of the methods that came before it, but it’s extremely important to recognize that the one group that’s keeping Typekit from almost universal compatibility is Firefox. I have no evidence to support this, but I imagine that Firefox users are among the quickest to upgrade, which would seem to suggest that this compatibility gap could be closed relatively quickly. Data shows that Firefox 3 is already used by 11 times more people than Firefox 2, and considering it was released just short of a year ago, this sort of upgrade pattern is encouraging.

Given the above data, combined with how often Firefox seems to annoy me these days with upgrade notices, I expect Firefox 3.1 or greater to be the dominant Firefox version in use one year from now, thus pushing Typekit’s compatibility percentage into the upper 90s fairly soon.

It’s also important to praise what Small Batch has done here on the compatibility front: their killer concept was involving type foundries in web-only licensing and propagating the font files through the standards-complaint @font-face CSS declaration, but they realized their solution would be academic if it didn’t work in Internet Explorer, so they made sure their backup implementation using EOT files took care of all IE users. The lack of this sort of practical thinking is what keeps a lot of great ideas from gaining traction on the web.

I also think that designers these days, self included, are a lot more amenable to things looking great on “most systems” as long as they at least work reasonably on other systems (as long as they look great on the particular system the designer uses). This is a bit of designer bias, of course, but it also represents an increasing desire in the design and development community to leave the old web behind. I still remember how much crap I took at ESPN from validatorians when we decided to leave Netscape 4 — with its 1% marketshare — behind. Now it’s all the rage… and I love it!

Functionality

By all accounts, Typekit will be more functional than any method that came before it. This is quite obviously because it uses a browser’s native font rendering technology. There are some concerns about reliability gaps stemming from downloading fonts off third-party servers, but I believe this fear will prove unfounded. Additionally, I imagine both the @font-face and EOT versions of fonts will come in larger files than sIFR font files (because usually you only embed a subset of characters in a sIFR font file) but with broadband penetration being what it is today, this too will prove immaterial. Additionally, even though sIFR font files may be smaller, the noticeable delay in rendering them probably more than makes up the difference.

Legality

I put legality in the middle of the pack and not at the top because, to my knowledge, there haven’t been any serious legal dust-ups over the use of technologies like sIFR and Cufon. So far, the burden has been on designers to buy the fonts they use before embedding them using sIFR or Cufon, but at the same time, there’s been no clear blessing or condemnation of this practice by foundries or type designers.

The nice thing about Typekit is that it specifically involves foundries and type designers in the process of licensing their fonts for use on the web. When you use Typekit, you know with certainty that what you’re doing has the direct blessing of the people who created and/or marketed the typeface you’re using. This is a nice piece-of-mind upgrade as well as a way of further compensating type designers for giving us the building blocks of web design.

Ease of use

Typekit promises to be easier to implement than either sIFR, Cufon, or any other font replacement technology. I guess we won’t know until we start using it, but it would shock me if it took more than a few minutes to implement, including licensing the font you want to use. sIFR’s second most common complaint other than “it uses Flash and Flash kills puppies” is that it’s a bit difficult to implement. Typekit’s improvement on this front will be more than welcome.

Hackiness

First let me say something I’ve said many times before: the entire world wide web is a hack. Get over it. Secondly, however, any technologies or methods — that work — which serve to dehackify it a bit are welcome. Typekit certainly dehackifies custom typography on the web by leaps and bounds. It was the solution we all knew would come eventually when we created sIFR as a stopgap five years ago. Just about the only things hacky about it are that it falls back to EOT (which, as discussed earlier, is great) and that it uses Javascript to handle the licensing nuts and bolts (meh, big deal).

Conclusion

Typekit is likely the best thing to happen to web design since the re-emergence of browser competitiveness. It will be embraced quickly and fervently when it is released this summer, and its creators should be loudly applauded for doing it instead of just talking about it. There are too many talkers in the world and not enough doers. The team at Small Batch has done an excellent job of taking a problem that a lot of people like to talk about and solving it in a practical, equitable way. It’s a welcome solution to a real issue and a significant step towards a leaner, Veener web.