Last week, Typekit was revealed with the promise of finally bringing rich typography to the web. The response was huge, as it should be, this is a big deal. Not to mention It was started by very smart people. But…

I wouldn't exactly call it the silver bullet to end type blandness¹ on the web. The announcement post did not include much detail in the way of specifics; so naturally people tended to fill in the blanks with assumptions and speculations. (Which is a large part of what I'm doing with this post.)

At first there was thought that this was just another JavaScript replacement technique along the lines of sIFR, Cufon or typeface.js. It seems that this confusion has been cleared posthaste, but to be sure Typekit is definitely not a JavaScript replacement, which is clear from the inaugural blog post:

Every major browser is about to support the ability to link to a font. That means you can write a bit of CSS, include a URL to a font file, and have your page display with the typography you expect.

If you're still not convinced, read the update on Webmonkey's article on Typekit. Specifically:

“Typekit isn’t using any sort of image replacement for rendering fonts on web pages,” Veen tells Webmonkey. “We’re using the CSS @font-face declaration to link to TrueType and OpenType files. We’re using JavaScript to simplify that process and account for various browser versions.”

One thing to keep in mind when discussing Typekit – smart people are running this thing. That being said, I do have my own hesitations regarding Typekit that I've outlined below.

1. Browser Rendering

As I wrote previously on this site, native font rendering on Windows for certain typefaces is awful. I don't know of any way around that, so I predict that until that gets better using PHP to specify our font stacks for multiple operating systems will become a common step in building websites.

However, this is not the end of the world – is really Window's problem – and hopefully will be fixed in the future. And since there's a readily available fix in the meantime, it shouldn't be a limitation that keeps us from bringing beautiful type to the web.

2. Pricing

First, let me make it clear that I'm all for the exchange of money for products and services. An entity like Typekit can't exist without charging for their product. Whether it's a one-time fee or a monthly subscription, at some point we have to realize that doing business comes at a cost. Not to mention that unless it's a personal project you can offset the cost to the client; and if they don't want to pay extra then guess what? You can still create beautiful work with Helvetica and Georgia.

That being said, I foresee that most designers will be double-charged because in most every case it would be necessary to own (as in on the computer) the typefaces used on the web. Reasons include:

• Using the same fonts in mockups when presenting the website to the client,
• creating web graphics that match the site's design,
• and building a type library for other projects.

The latter reason is not necessary, but I imagine is most everyone's preference. However the first two are quite relevant, especially if you're replacing full copy. You can't show a client a mockup in Helvetica and tell them that it's going to be in Gotham on the web. (Though, as kudos to Typekit, I can't believe that I'm even writing that previous sentence as a possiblity.)

For me, the reasons mentioned above necessitate using Typekit for typefaces that I already own. Essentially then you're paying twice for a typeface. Once for the desktop, once for the web. Though an argument can be made that if an eventual web-friendly EULA was adopted for typefaces it would likely include having to pay an extra fee to the type foundry anyways. In this scenario the twice payment objection is moot if the pricing for Typekit and the web fees for type foundries are comparable, but at the moment nothing of the sort exists.

3. Whose Server?

The one real hurdle that I cannot get over is no matter what licensing, pricing or technological breakthrough: I'm linking to someone else's server for 95% of my design. Even if the server has 100% uptime, that's still a huge mental barrier for me to cross. Maybe it's just me? I can't tell. Perhaps I need to accept the fact that this type of technology sharing will become more commonplace as internet connectivity advances.

For now though, that will probably be what keeps me from using Typekit for my own sites. For client sites I see a brighter outlook because they may not have the same hang-up about where files are hosted as long as everything works. Though, on the matter of clients, Elliot Jay Stocks raised a good point in his comment about the longevity of Typekit type choices on Kyle Meyer's post on Typekit.

Unsure

On some level, I feel like the kid who's been offered the candy store and then complains because it won't fit in his bag. But on the other hand I cant help but think that this is not the solution for which we've all been waiting. Though I imagine that if many of us were asked how to solve the font licensing problem we'd all conclude that some sort of external server authentication would be required. Perhaps we can persuade the internet not to steal?

Finally, I want to end on a positive note. I appreciate the hard work that has gone into Typekit and the leadership shown by Jeffery Veen et al to connect the web community and type designers in a positive and forward-thinking way. This is a step, a huge step, towards working together to develop a technologically mature and elegant solution to type on the web.