#69: First Ten Minutes with TypeKit

I got the invite from TypeKit, signed up, and had beautiful custom fonts rocking my page in just a few minutes. I'll show you the entire process from start to finish, as well as touch on the advantages and disadvantages.

@ConCy A better solution may be to use visibility: hidden; instead, as this allows the elements dimensions to be calculated properly. I have been toying around with this a bit on larger-scale sites, to reduce the “flicker” often seen when waiting for all server transactions to be completed.

It’s a fairly elegant solution and way easier than any of the other solutions Chris mentioned. I do, however, question loading the entire jQuery library regardless if it is loaded prior as it is in the example. Instead, it might be beneficial to check if jQuery has been loaded and load it if not. The fact that it is loaded twice, certainly will attribute to the delay, albeit minute. @Jaymie This is most likely the cause of your issue, as you may be using an older version of jQuery which may conflict with the version being loaded by TypeKit.

Unfortunately, the “protection” offered for the fonts is slim at best. Each font is simply base64-encoded. With a little bit of know-how and a minute or two of time, the font can be “yours” quite easily. I’ll be curious how quickly their library grows based on this fact.

And as we’ve seen over and over again, those with enough time and talent will find ways around any attempt at security. The reality is that there are countless places that make it far easier to steal fonts, if that’s your goal.

Our goal is different. After talking to dozens of foundries, we’ve found traction with a solution that works today and moves the conversation forward. With it, we hope to provide the easiest place to use real fonts on the web, legally and licensed, and to compensate type designers for their amazing contribution to visual communication.

What is think is really cool about this is that it doesn’t make you hassle with buying seperate fonts and managing each purchase seperately. That has been my major deterent to using custom fonts. I didn’t really know how to easily do it legally in the first place. It is nice to have it just taken care of.

Once again to the “flashing-thing”… I’m pretty sure that this can’t be avoided cause the Javascript which is doing the replacement-magic needs its time to load – and I could bet that the more fonts you use, the longer it will take to replace the fonts on your page. I played around with cufon, sifr, typeface and flir.js (which works serverside with the dynamic generation of images), but everywhere, there is a little flash included. I just don’t think that it’s a good solution to work with “visibility:hidden”, until the font-replacement-plugin of your choice has done it’s work, because
a) what if users have js turned off? They can’t see anything which you have replaced, if you don’t work with ugly things like to override that visibility:hidden-thingy and
b) it’s just even more ugly to see the new fonts come flashing out of the nowhere and people might have already left your page if it seems not responsive enough

Good point about users with JS turned off. You could get around that by switching the display attribute using JS itself, since only users with JS enabled can benefit from this type of font replacement anyway.

My TypeKit account request hasn’t been answered yet, so I don’t have the ability to test this, but I think the following may work:

(1) After you have linked in the jQuery library, include a line of code to hide the visibility of each element that a TypeKit font is being applied to:

$("h1").css("visibility","hidden");

(2) In the second script element provided by TypeKit, add some code, so that INSTEAD OF this:

try{Typekit.load();}catch(e){}

it looks like this:

try{Typekit.load();}catch(e){}$("h1").css("visibility","visible");

Note again that “h1” should be replaced in both cases with whichever elements your Typekit fonts target.

What we want to happen here is to switch visibility back on as soon as the font replacement has happened. I don’t know enough about writing callbacks to be confident my approach will work. In fact I would assume it won’t because I don’t know what’s happening in that code Typekit is providing. It would be interesting to try, though!

And even if this does work, it’s a bit of a hack, which is a shame. The promise of Typekit is to be plug-and-play, right out of the box — which this definitely isn’t.

In my first paragraph I referred to the “display” attribute, but actually meant the “visibility” attribute.

As other have pointed out here, the benefit of the visibility attribute is that it doesn’t remove the element from the flow completely, and preserves its dimensions. Doing this with “display” would replace the icky flash with an icky jump.

thanks for your explanation. I previously thought that you wanted to hide all elements you want typekit to replace via css-rule “visibility:hidden” which would be indeed stupid because of the mentioned problem with users without js enabled. Using jQuery instead to toggle the visibility is definitely a better, more sane approach.

But I still don’t understand completely what you’re trying to do by manually influencing the visibility. The process would be the following
1) Hide all elements which typekit is applied to, before they appear on the screen (document.ready).
2) Let Typekit render the fonts
3) Show the rendered elements when they’re done

BUT: You’ll have to wait until everything is completely rendered, before the user sees anything on the screen which might look even slower.

That’s really cool, thanks for this great demo, I can’t imagine how beautiful the web will be after this works, I only hope that they support Arabic fonts as I live and design for the Arab world you know.

I am using Typekit in the free version and it is not allowed to remove the budget. But for free…
Anyway, it is very easy to manage the font for the website. I have two options of fonts in this version.
And I had the problem with the jquery stuff too.
But it worth it.

I like it. As with most of the people here, the flicker does bother me a little. I can’t think of any great options other than:

1. as mentioned, keep its visibility hidden until the work is done; but being a JavaScript numpty, I’m not even sure how you can hook into the script properly…

2. if you can figure out how to do #1, you could alternatively display rendered text until the real text appears. Obviously this causes server load and somewhat defeats the purpose.

I don’t know enough about web technologies to describe “how”, but I wonder if something could be implemented on the server side to get the heavy lifting done (and cached) before the client request comes in? Also wonder if the results of executing the JavaScript can somehow be cached on the client side, so that only the first visit to that site causes the flicker, and subsequent visits are more seamless…?

I don’t know. I ramble. Half-bakedly.

Cool technology, though, and seems to be a lot easier than the alternatives.

hey question, Chris i have watch ur screen cast for a while, i wondering can you using the fonts i desire the use instead the fonts they provided because you no some time if you they end up done have the font you’re looking how would i do that?

Chris, this is amazing. I do think they just need to tie a few loose ends (like the loading time, and copy -the-class ability). Other than that, I’m super excited about it and can’t wait for it to be released. Thanks so much for sharing it.

First Chris, thanks for all your wonderful tutorials. A fantastic resource. I am contemplating about this whole issue… this font-snatching-from-a-third-party thing relies upon TypeKit to be up and running right? And in business for the lifetime of the website? This dependency may be worth a thought, I think.

To get rid of the Flickr, create a separate CSS file called hidden.css. Within this CSS file, list out all the selectors you want the “visibility: hidden” property applied to.

In the head of your document, load this hidden.css file into your document using Javascript. This way you don’t break the JS:Off/CSS:On scenario.

To get the fonts to appear back again, you’ll need to listen for load event on the font file. Not sure if TypeKit has a callback implemented for this or not yet, but it shouldn’t be too hard to go through their code and build a solution from there.

I work at a fairly prominent type design studio and we have been toying with the idea of @font-face for a while now. Typekit looks like a wonderful solution for most people but I would expect this to be the tip of the ice burg. I would expect Linotype, Adobe, FF, and other large type publishing houses to start building similar tools, if they have any brains.

Also expect to see a lot more really cool and really customizable solutions from the independent studios ;)

Hi! This is my first post, I am from Argentina and my english is so bad, please forgive me! Well, I had seen some videos and all were do usefull for me. But know i have a question… why do not you use sFIR? I think that give the same solution, is free, and you can have the requiere files on your own host

As far as I know: sIFR uses flash to generate images of the letters (correct me if I’m wrong =D) and thus they aren’t selectable as text…like Chris said, there are 5+ ways to do the same thing and this is an elegant one that comes to the list!

sIFR does create a Flash object to render the letters, but within the object itself, the text *is* selectable. However, you run into a problem if you want to select any part of that text along with other text on either side of the object. Such contiguous selections, crossing over from Flash to HTML or vice-versa, cannot be made.

Posting Code!

You may write comments in Markdown. This makes code easy to post, as you can write inline code like `<div>this</div>` or multiline blocks of code in triple backtick fences (```) with double new lines before and after.

Code of Conduct

Absolutely anyone is welcome to submit a comment here. But not all comments will be posted. Think of it like writing a letter to the editor. All submitted comments will be read, but not all published. Published comments will be on-topic, helpful, and further the discussion or debate.

Want to tell us something privately?

Feel free to use our contact form. That's a great place to let us know about typos or anything off-topic.