Examining Typekit
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.
While I agree with most everything you said in each of your five characteristics, I still have some lingering concerns that will keep me from calling TypeKit “the best thing to happen to web design since the re-emergence of browser competitiveness,” at least until I get some more info. Among them:
1. What will it cost?
2. How will the plans be structured? Per-designer? Per-font? Per-site? Based on bandwidth usage? Per-something else?
3. Just how many foundries will be on-board? Will I be able to get my favorite font?
4. What’s the lock-in like? How easily can I get out of using TypeKit once I start?
5. This is the big one: Will it scale? When Doug Bowman decides to implement TypeKit on Twitter, will TypeKit go straight to hell, ruining it for the rest of us? Will we start seeing TypeKit-powered sites hanging as we wait for the Javascript bits and font files to load?
Don’t get me wrong: I’m excited about the potential here. Really excited, in fact. I think Veen and his team are amongst the absolute best minds in the industry and I have nothing but faith and trust in them. But, all we *really* know about TypeKit is what we learned in a pretty vague product introduction blog post. We haven’t even seen an example, let alone the thing working in the wild.
So yeah…awesome-sounding stuff, but I’m going to hold my horses just a little bit before I bestow any more Godliness on Veen than I already do…which is a lot.
I too, am skeptical until we hear a lot more details. Rather than the solution we’ve all been waiting for, I feel like Typekit may be just another OK solution to add to the mix.
If it uses @font-face, then why do we still need to depend on javascript? How big will that javascript and font file be (and take to download) and how will that effect text rendering time vs the current methods? If I’ve already paid good money for a font, why do I have to pay again to use it on the web? Isn’t Typekit just font DRM (and don’t we all know that DRM is a failing model)?
Typekit may solve some problems, but it introduces just as many more. It’s like an episode of LOST. I can enjoy the ride, but I’m really waiting for the day when all of these web font hacks are over and we have true, free, no-string-attached font use on the web. I don’t think Typekit is that finale. Not even close.
Agree with the two posters above. Without more details about price, real performance, and terms, it’s too early to get excited.
Jeff Croft asks the questions that certainly need answering before we can wholeheartedly embrace Typekit. But, like him, I’m excited about the possibilities latent here. And here’s the thing: if Typekit blows it, someone else will do them one better.
Also, Mike, a technicality: Firefox 3.1 was rebranded as 3.5 to reflect the amount of new functionality (and length of time to get out the door). The RC is set to drop in early June.
Jeff, Benek, and Nathan: I think you are right to be asking the hard questions, but I also think you’ll probably be pretty happy with the answers (even though we don’t know them yet). People like Veen don’t stick their neck out and create projects like this if they aren’t relatively sure they can provide a good value proposition. Here are what I would guess would be the answers to your questions, Jeff:
1. Probably $0-$100 per typeface, per domain, depending on the typeface.
2. Per domain.
3. Several to start out with, but not all of them. With time and more peer pressure, more will jump on board. Since your favorite font is Giddyup, probably not.
4. The “lock in” is that you bought a per-domain license to use a font via the Typekit system. If you want to do something else later, then go ahead.
5. Scalability should be a non-issue. I’m sure whatever can be served off a CDN will be, and whatever can’t will be nicely supported.
Benek: If you go to Jeff’s V. site, I believe you can see it in action, somewhat. The JS file appears to include bits of JQuery and weighs in at 21k gzipped while each font file weighs in at about 25k. Not too bad. What’s less than impressive though is that, at least in Safari, I get a 2-10 second lag before the right font pops in. If this is how the method performs upon release, it would probably be pretty unacceptable (slower than sIFR, Cufon, and other methods). To answer your other questions, the javascript is required as an authentication layer. Does this amount to a bit of DRM? Sure, but it’s better than the current alternative of some type foundries not even allowing their fonts to be embedded online at all. I personally think the model of making a designer pay a ton of money for a full font license (often several hundred dollars) if they just want to use it online is troublesome. The concept of licensing an online-only version for a reduced cost is appealing to me. That way, the designer can use whatever typeface they want, pass the small cost on to the client, and then repeat for every site they design. Also, you mentioned you want to have “true, free, no-string-attached font use on the web”. This suggests you don’t feel that typefaces are worth paying for. Is that what you’re saying?
Matt: Thanks for the heads up on Firefox 3.5.
[…] Examining Typekit […]
@ Mike D., re: the required Javascript — what exactly is the Javascript going to do? Couldn’t we see something like this:
@font-face {
font-family: “Adobe Avenir”;
src: url(“http://fonts.typekit.com/avenir.ttf?key=#######”)
}
Couldn’t that key plus checking the domain be enough to protect the font? Using Javascript for “DRM” just seems like obfuscation instead of real security.
Scott: At least one thing the Javascript will do, presumably, is determine the font format that needs to be used, based on the browser.
If javascript is needed to get the font to load, the percentages of browsers it works with will lower. I’m not sure how many people have javascript turned off, but I know it’s enough that you have to code intelligently.
If it guesses at the right font to load when javascript is turned off, that would solve that problem.
Is the wait-time based mostly on download speed or javascript ability? I load the font on Veen’s page in less than a second, which is good.
If Typekit is only selling new licenses specific to a domain, what incentive will people have to buy those licenses when they have already purchased the font files themselves and already have a license to use it in their designs? Essentially all they would be paying for is public proof that they have a license.
I don’t see how something like that will take off unless they are offering something fantastic on top of the licensing (i.e. a great standards-compliant way of embedding fonts that deals with browser inconsistencies transparently, and perhaps a convenient way to manage your font files online).
Otherwise, why would someone who has already purchased a license to use a font in their designs want to purchase another one just to use it on a specific site when they aren’t required to?
I’m hoping they let you upload your pre-purchased font-files and simply provide hosting for them in some encrypted format that protects them from digital piracy while still making them publicly available in your designs. I think people would pay for that, but I can’t see them paying for individual licenses for individual sites.
@Mike re: “The concept of licensing an online-only version for a reduced cost is appealing to me.”
The issue with this is that a designer would still need to pay for the full version of the font license to use it in their design mockups or any offline version of the final web design. I just don’t see what incentive designers will have to bother buying typekit licenses at all if they are just DRM.
John: The question of existing licensing is a good one, and one I didn’t cover. Forgetting about the past, I would imagine “web embedding via Typekit” would be either an additional add-on of a full license or included in the full license. Either way is fine, really, as it’s just a matter of cost. In other words, if the full license is $299 and includes embedding, the way it would work under the other scenario is the “regular” license is $249 and the embedding license is $50. Something like that.
Now… with regard to the past, that’s going to be a bit trickier perhaps. The foundries could take the stance that this is new functionality that nobody has previously bought a license for. In this case, you’d be on the hook for another $50 or whatever. Or, they could try and somehow make good with existing licensees. That seems like it would be tough though.
If Typekit can license fonts, why cant I and cut out the middle man and the risk of hosting important files on a 3rd party’s server? Are the foundries charging $5000 a font? If they come up with some magical code that prevents downloading the font files, what’s to stop someone else doing the same and I just implement it on my own site? Also, why are fonts any different than using stock photos? Why are they special? Or should some enterprising 3rd party come up with Jpgkit to host all my paid for image files for me.
I love custom fonts, but am so not interested in TypeKit.
In the first place, I already have custom fonts in Flash since 1997, and we only do Flash for IE anyway. We absolutely do not spend any time with MSHTML or any of Microsoft’s playthings because we are publishing professionals, not computer gamers. One Flash 9 presentation runs on all IE since 2000 in exactly the same way.
Secondly, the whole idea of HTML 5 is to define one “right” way to do things for both Web author and browser maker. No more hacks. Not interested.
Finally, I already paid for all my fonts, and if the foundries think I’m paying again so I can have “Web publishing rights”, I will buy clones of the fonts from someone else or make them myself. I’ve been publishing this font collection on the Web since 1997 via Photoshop, so I already have Web rights.
I think the real question that needs to be asked is how Typekit is going to attempt to protect commercial fonts, as they claim it can (at least to “the level of protection that type designers need”, whatever that is). The @font-face browsers don’t support any kind of “copy protection” on fonts. Just adding some obfuscation through Javascript isn’t going to make them support it. At some point the browser will need to be given the raw font data. I suppose Typekit is going to try to hide that using “data:” URIs and such, but anyone with some technical skills should still be able to grab those fonts, AFAICT.
If I’m right, and if the foundries are aware of this, there may not be all that many commercial fonts available through Typekit. And then the only remaining value it would provide would be the EOT compatibility.
wwew: You can’t cut out the middle man because you’re not the one putting the effort in to sign all of these foundries up and create this system. The middle man is doing exactly what a good middle man should do: provide value to the end men.
Hamranhansenhansen: Jigga what? I didn’t understand more than about a sentence of that. You use Flash only for IE? Flash 9 has been out since 2000? You have web embedding rights because you can save things in Photoshop? Wha?
Christopher: I think that anytime you try to digitally protect something, you have to pre-concede that it will be cracked. However Typekit intended to run their system, you *will* be able to hack around it, download a binary, and run some sort of version of font embedding without their help. But you will be breaking the law by doing so… and I imagine it would be pretty easy to discover. Foundries really have no reason to be against Typekit because their stuff is already being pirated hand over fist. This finally gives them a way to at least try to give the public what they want in a legal, trackable way.
The speculation here is pretty amusing- nothing exists publicly yet. Give it time. It’s an interesting, timely idea that may or may not pan out. We’ll see- and I wish them well.
I also think it’s amusing that Veen is considered a “god”. When’s the last time he did anything to change the web since writing for Web Monkey back in the day?
The latest Typekit blog article answers lots of these questions:
http://blog.typekit.com/2009/06/02/fonts-javascript-and-how-designers-design/
@John Fredrickson re: offering something more than just licensing; the JS injects the correct CSS rules, handles OTF typography features like ligatures (nice!) and provides some fallback for older browsers. You can also link directly to font files if you want. Finally I’d say the biggest service they’re offering is things just working—anyone wondering why people would pay money for something already done natively in the browser has not had the pleasure of using .eot :|
@Mike.D re: Safari load lag; this will probably be due to Safari not rendering anything while the font downloads:
https://bugs.webkit.org/show_bug.cgi?id=25207
This will probably be addressed in Safari by using the first local font if the linked font hasn’t downloaded in a couple of seconds, and in general by subsetting/gzipping. However it seems that Typekit’s JS will control how the font downloads and when it is rendered, getting around the ‘no content while font downloads’ issue. Maybe they’re still working on this bit? :)
Personally I think the last piece of the puzzle will be automatic subsetting, ie Typekit detecting content changes on your site and autogenerating a new subset font. This isn’t a big deal for latin fonts, but at 500KB+ per face for multibyte fonts it is (!)
Bonus titbit: Clearleft is also working on something similar, although with a potentially different method:
http://forabeautifulweb.com/blog/about/why_typekit_will_change_everything/#r1001
Exciting times, people!
Typekit sounds very promising. Not so much the solution but more the fact that foundries are seemingly relaxing their neurotic stance on font licensing for the web.
My main issue with Typekit, other than remote loading of fonts, is that I may need to buy fonts more than once. Not a good idea. This solution may, in the end, be the thin end of wedge of font piracy. Someone is going replicate Typekit and figure out how to host files elsewhere. Maybe even a bittorrent like solution for all I know.
Typekit is indeed for better or for worse the beginning of a new era in web typography.
I can’t see Typekit as any more than yet another half-way hack, it’s only unique feature is the licensing, and that’s only necessary because foundries are control freaks with irrational fears about font-piracy via web font embedding. I wrote more in in a blog post ( http://perlucida.com/blog/internet/typekit-another-half-arsed-attempt-at-getting-a-wide-range-of-fonts-on-the-web ).
I don’t doubt Typekit will have certain use cases, but the compromises will be too many for any real revolution.
At the end of the day all of the features and potential benefits of this solution are overshadowed by the fact that it is a DRM system. There is no such thing as a “bit of DRM”. It either is or it isn’t, and this is. I hope that most people are able to recognize it as such and hold out for a more open DRM-less system.
[…] Examining Typekit – Typekit is likely the best thing to happen to web design […] – So […]
@Rilly I’m not sure that it’s DRM per se that is a problem, but rather that it’s a hackish attempt to layer font DRM onto the web.
It just reminds me of of all the umpteen DRM/anti-piracy technologies that were tried with CD’s, were easily circumvented and thus completely pointless inconveniences to honest customers. Even ‘easy’ DRM like Apple’s fairplay/iTunes ultimately seems to be giving way to DRM-less digital music.
Sooner or later one major foundry is going to wake up, EMI style and realise it can make more money selling customers what they want than putting pointless barriers up that degrade customer experience. But perhaps they just need to go through the process like the music companies did.
It’s possible a proper DRM system could be developed, but it’d need foundry support, OS vendor support (including Linux) and browser support. We’re talking 10-20 years at current rate of progress. In the mean time how much money are the foundries losing by not having DRM-less font licensing for the web today? How much have the lost over the last 10 years?
I’m tired of telling designers and customers “No, you can’t have any font you want” and I don’t see Typekit changing that.
As ever I think Jeff Croft is the voice of reason around all the hype. I believe I will reserve my judgement until examples appear and the price plan is revealed.
All in all a great effort. Using one browser dependent language/technology less then other solutions (Flash) with this great compatibility result is definitely a step forward in this big webdesign issue.
But if Typekit is going to cost $0-$100 per typeface, per domain, depending on the typeface, then it is $1-%100,- more expensive to use then sFIR, whilst both do the job with almost the same result for the visitor of a website.
In my honest opinion: However great the solution might be; if it will cost money, I do not see it taking of bigtime. Even if the solution only use CSS, was W3 supported and 100% browser compatible, since the costfree solutions are accepted as good enough by almost all the clients I know. I doubt if they want to pay for this almost perfect solution. But then again, if my predictions where always right, I would have been floating on an air mattress on my private island in the sun right now, wondering why the butler did not bring my drink yet.
Ah here come the anti-DRM freedom fighters…
Lieuwe: I don’t mean that Typekit itself will cost 0-100 bucks per domain… I mean that the license for the typeface will cost that much. With sIFR, you still have to pay for the *full* license for the typeface (rather than just a web-only license) so my hope is that Typekit will actually be *cheaper*, not more expensive than sIFR.
[…] Examining TypeKit Why TypeKit will change everything TypeKit — another layer of complexity […]
[…] the various opinion pieces: Andy Clarke offers a very thorough walk-through of the service, and Mike Davidson examines (among other things) the question of Typekit’s compatibility reach. Because of these posts (and others, of course), there seems little point in me repeating the […]
[…] sites hanging as we wait for the Javascript bits and font files to load? -Jeff Croft, opinando en el post dónde Mike Davids analiza Typekit, vía […]
[…] the various opinion pieces: Andy Clarke offers a very thorough walk-through of the service, and Mike Davidson examines (among other things) the question of Typekit’s compatibility reach. Because of these posts (and others, of course), there seems little point in me repeating the […]
Actually, one member of The Web Standards Project (me) praised you to the skies for redesigning ESPN with web standards and promoted you and your work widely. Another member of The Web Standards Project claimed it was wrong to call the ESPN “standards-based” if it didn’t validate. Neither of us was speaking for the group. Most followers of The Web Standards Project got that you had done something important for standards-based design. If they didn’t get it at first, they surely got it when DWWS 1e came out, praising what you had done.
The WaSP never issued an official statement about your work, nor did anyone from webstandards.org, to my knowledge, criticize you for blocking Netscape 4 — something we had done (and A List Apart had done) years earlier.
I respect you so immensely for your achievements as a designer, publisher, and thinker. And your words mean so much to so many people who read you. I wish you stick to the facts and stop making The Web Standards Project a goat simply because you had an unpleasant email exchange with one member of The Project, who was speaking for himself.
[…] far these solutions have generated a lot of debate, but very little consensus. Designers aren’t really keen on new font formats. Adding support […]
[…] the various opinion pieces: Andy Clarke offers a very thorough walk-through of the service, and Mike Davidson examines (among other things) the question of Typekit’s compatibility reach. Because of these posts (and others, of course), there seems little point in me repeating the […]
[…] best thing to happen to web design since the re-emergence of browser competitiveness as voiced by Mike Davidson back in May? or is it a false dawn for web typography. Leave a Comment No Comments Yet so far […]
zeldman: I’m late in replying to this, but when I first read your comment, I had to think for a second what you were referring to. Then yes, I got it: you’re referring to the linking of the word “validatorian” to the WaSP, and you’re correct in that I am not — and should not be — referring to everyone involved in the Web Standards Project. My early interactions with WaSP were colored by the actions of one overly combative individual on staff and in the end, everything worked out ok. As you already know, you were one of the voices of reason throughout, and I will always appreciate that.
[…] [3] Examining Typekit, May 31st, 2009 (https://mikeindustries.com/blog/archive/2009/05/examining-typekit) […]