Fred Boyle // November 8, 2010

Typeface adventures - Typekit, @font-face and mobile

Typefaces and the web — an age-old battle that is just now coming to an end. Until recently the only ways to get beautiful type on a web site was to use images, with technologies such as sIFR, Cufon, or other replacement technologies. Now we have the mighty @font-face allowing us to embed typefaces in our sites. The catch-22 of @font-face, however, is the legality of using a typeface; this is where services such as Typekit, Fontdeck, Fontspring and others come into play. But there are some issues to consider when choosing a service or approach to use, which we encountered with the nGen Works site.

One issue was with Typekit, the most prevalent typeface service I can think of and the one most of you are likely familiar with. They offer many excellent typefaces and have good price points. After the great Tungsten debacle, see Jeff’s video post for a bit more info, we implemented Typekit using the Vinyl + FF Tisa typefaces. This was easy and looked great. As we were doing some testing and getting feedback from all of you, we ran into a few issues with Typekit, chiefly on mobile devices such as the iPhone and iPad.

So what was going on? Safari on the iPad would crash. In app mode, when a site was saved to the home screen and launched without the chrome (address bar, etc), typefaces weren’t loading. In-app browsers experienced the same issue. We also encountered cross-browser problems, such as IE7 not loading typefaces.

To solve the problems, we started by contacting Typekit. They began (or, in some cases, were already) working on solutions. Without an ETA for fixes, though, we continued our own testing and research. More details on the iPad crash issue, which is actually an iOS 3 bug, were available and led us to understand how we might work around it. You can read a great synopsis of the issue here.

Through additional research and further discussions with Typekit on the app mode and in-app browsers issues, we learned these were due to the browser agent/identification string provided by Safari in app mode, and in-app browsers, is slightly different and not recognized by Typekit’s Javascript loader.

To make sure our site looked its best in the greatest number of places, we decided not to use Typekit for our header typeface, Vinyl, and looked for a typeface we could load directly without the use of a Javascript loader. This would allow us greater control and flexibility in working around some of the bugs and issues we encountered. We ended up purchasing Trump Gothic East from Fontspring. What makes Fontspring different from other services is that you purchase traditional typefaces you can install on your desktop but you can also add an @font-face license which provides you everything you need. Since we were able to define what was being loaded and how, we were able to work around the iOS 3 bug and crashing iPads. And, since we were no longer using a Javascript loader that performed browser detection, it automatically eliminated the app mode and in-app browser issues, as well as the IE7 issue. So by changing our approach, we were able to control the situation more precisely and work around bugs and issues.

A disclaimer: Typekit has since provided fixes for some of these issues, and we are by no means advocating that anyone not use their service. In fact, we continue to use Typekit for our serif typeface, FF Tisa. Since FF Tisa has a tolerable common fallback of Georgia, we only needed to work around the potential iOS 3 bug and crashing iPads. We did this by doing a browser agent check for iPads and preventing Typekit from loading. This stopped the crashes in our situation.

It’s been an adventure to get our site to look sharp with great typefaces on as many devices as possible, but we’ve learned a lot. Although typeface use on web sites has come a long way and become easier, there’s still a lot to keep in mind, particularly when mobile devices are involved.