http://lucksy.com/sandbox/typekit_plugin_for_wordpress/

Hope you like it. :-)

Essentially I believe that if you are serving up content to your users on the web, you need to accept that they are inherently going to have access to that content. If we serve up a CSS file (or an image, or a JS file) to the user’s browser, the user is of course going to have access to that file, because you sent it to them!

CSS and fonts essentially perform the same function – they are used to style content. However with Typekit we are saying yes, we still want to serve up something that the browser will use to style some content, but for legal reasons we don’t want a human user to be able to access that styling information, because they may take it away and apply it wherever they want.

I feel this is contradictory to how the web works – we serve stuff up to people’s browsers that we are comfortable with them seeing, and stuff that we don’t want them to see stays server-side. Typekit goes against this paradigm – it serves stuff up, but pretends it hasn’t, or does it in such a way that a human user won’t be able to interpret and reproduce it.

In practice, my big issues with it are the big Flash Of Unstyled Content I get when loading the page, and the fact that there are still going to be inconsistencies with how the fonts are displayed across browsers and systems. I get the feeling from the comments I’ve seen that many of our more heavily design-oriented colleagues are expecting the pixel-perfect text rendering they now get by using Flash or images.

I can’t wait to use this on one of my designs!

To address this, our current technology preview is aimed at developing and documenting how the browsers render fonts, working with type designers to optimize existing fonts for the web, and iterate how we serve fonts quickly to address issues we see in the wild.

Unfortunately, @font-face is not something the browsers handle consistently. We use Javascript in Typekit to negotiate different font formats and implementation issues between the browsers that support the technology, provide alternatives for those that don’t, and give us an opportunity to update and add additional features as the browsers mature.

We’ve written this up in more detail here: http://blog.typekit.com/2009/06/02/fonts-javascript-and-how-designers-design/

Also, thanks for the great write-up, Keir.

There’s no JS in this example, but when I click that link I’m sent too far down the page. My guess is that my browser (Safari 4, Mac) calculates the height of elements before the type finishes loading.

No subscription … no 3rd-party server reliance … no JavaScript reliance … easy to use. It’s not (yet) ideal, but possible and IMO way better than TypeKit. ;-)

Cheers,
-stk

This is a wonderful step-by-step, Keir. Thanks for sharing.