Font Hybridization in HTML 5

Over this Christmas break, I was over at a friends house and got to sit down and tinker with my friends Mac. I’d forgotten how good fonts look, and I suddenly realized why so many sites are now using custom web fonts. Since I primarily use Windows at work and at home, I get annoyed by fonts that are difficult to read or that don’t render well on the screen. Somehow, I’ve never been 100% happy with font rendering on windows. It’s been getting better, but it’s still not as good as a Mac is. Maybe its the screen, maybe its the OS, maybe its the app, maybe its a combination of all of the above. Because I’ve been on this HTML kick, and I’m on windows, I’ve tended toward Cufon as my font replacement tool of choice when building sites since it’s the only one that produces a “more-reasonable” output on my machine.

But Cufon by it’s nature has several drawbacks. First, you can’t copy and paste text rendered with Cufon. With most of the newer browsers you can select it, but there’s not much more you can do beyond that. So, I usually limit Cufon usage to titles, headers, and the more “design-ery” aspects of a page. Second, because Cufon is image based, if someone zooms in on your text beyond 100% Cufon rendered text gets all fuzzy the same way it would if you zoomed in on an image. And finally, because Cufon renders with javascript on the client, there’s no way to cache the text. Javascript is fast, but when you’re rendering a large amount of text on a phone, there’s usually not a good way around a flash of unstyled content. And it happens each time you go to a new page because it can’t be cached.

Web fonts on the other hand, allow you to use fonts in a very similar manner as if you had them installed on your device with native rendering by the OS. You can select, copy, paste, and use it as you would any other piece of text. Web fonts are cacheable, so although you could get a flash of unstyled content when you first visit a page, subsequent visits should render immediately. The disadvantage however, is the OS. On windows, the rendering of fonts just… Sucks. So people don’t use it.

But what if there was a way to do a hybrid between Cufon and Web Fonts?

Besides the rendering issue, Web Fonts are the best option. They’re the most flexible and the most future proof. But they still suffer on Windows, some phones, and on older browsers that don’t support the new @font-face CSS syntax. So what if we did a hybrid? Use @font-face, then fall back on Cufon for older browsers, and for windows. The advantage is that on a new browser the@font-face‘s will be cached, used for the initial rendering of the page, and then cleaned up with Cufon later.

Using Modernizr and a little custom javascript to do user agent testing I put together a page to test out the hybrid font idea:

It’s a rough draft. I have some screen shots below from both Mac and PC’s (click for full size versions).



For simplicity, the javascript code to test and load Cufon and my custom cufon polyfill looks like this:

function rendersNiceFontface() {
	result = navigator.appVersion.indexOf("Win") != -1 
		|| navigator.appVersion.indexOf("Android") != -1;
	return result;

var supportsNiceFontface = !rendersNiceFontface();

		test : Modernizr.fontface && Modernizr.canvas && supportsNiceFontface,
		nope : [ 'cufon-yui.js', 'BebasNeueRegular_400.font.js', 'cufon-polyfill.js' ]

Using the Modernizr yepnope.js, I’m able to completely skip loading Cufon at all if the browser supports good @font-face rules. There’s more that I’d have to do to clean it up before I’d use it in a real setting, but it demonstrate the concept, and is something I could definitely use later as a @font-face polyfill. It does have some drawbacks though, you have to maintain both your CSS rules and your Cufon replacement calls, and Cufon doesn’t work well with a large amount of body text, so if you don’t support @font-face, I’d fall back to a good secondary font and forgo Cufon in those cases.

I hope this got some gears turning, I’m looking forward to some comments.

An Introduction To Web Fonts

Back in the old days of the Internet, circa 10 years ago, people were just beginning to discover all the new cool things you could do with the web. Print was still around in full force in all its forms of magazines and newspapers. We even had individuals that made a living putting together and curating text based content. Over the years as more and more content has migrated to the web, one of the major limitations designers have faced is that they only had about 3-5 fonts that they could reliably use to format their text and be sure that the particular font they had chosen would exist on the users machine. Sometimes there would be variations, but those variations could never be guaranteed to render the same way in a users browser. Print was just extremely flexible and could provide a typographical brand and experience that the web simply couldn’t match.

As the web has continued to evolve through the browser wars and the waves of ‘web 2.0′ there was still very little change in the way text was shown in the browser. Over the last few years some of these issues have begun to be addressed, and there’s a growing amount of support in more modern browsers to express this new idea of web fonts. The core issue is that everyone is running on a different browser, different operating system, platform, or device, and each unique configuration has its own typographical settings, fonts, defaults and so on. Websites initially began experimenting with solutions to solve this issue by actually embedding a link to the font that the browser can recognize, download, cache, and use to render fonts it doesn’t already possess. But this also posed a problem: Type foundries don’t simply want their fonts to be embedded and freely downloadable and usable by whoever happens to come along and visit a site that uses one of their fonts. A font foundries whole business model is based around the licensing of the fonts they create, so having something ‘freely downloadable’ would never appeal to them.

As I have been doing some exploration on the latest and greatest of web technologies related to HTML5 for RECESS here at InterKnowlogy, I wanted to share two different approaches that I’ve found of companies that are exploring this somewhat new idea of web fonts. Chances are you may have even seen sites already that use this, but didn’t realize it or how they did it.

TypeKit –

Google Web Fonts –

Each of these take two separate approaches that may or may not be viable to you as a designer / developer / company depending on your needs. TypeKit is arguably the more powerful and flexible options of these two, but is a paid service (although very reasonably priced). It has a large portfolio of professional grade fonts from many different foundries, including some many of the main fonts that are included in Adobe products (which I’m sure is a plus for many designers). They uses an internal obfuscation and customization process to protect the individual font from being used outside of the website that the license was purchased for. This has allowed them to negotiate deals with some of these foundries to license the fonts for web use through their company (and they’ve obviously been decently successful).

Google on the other hand, has opted for the freely available open source fonts. All the fonts used in its web fonts site are free to use for anything and are supported on a purely donational basis. This provides two advantages: All the fonts are freely available, and a single browser can cache a font and use it across any sites that also use that same font without redownloading it, this means there will be less overhead and a more consistent experience across sites that use Google Web Fonts. However, arguably the biggest downside is that the selection of fonts is much more limited. Google has done a excellent job of curating the available fonts it has to ensure that they meet some internal quality standards, but likely many of the industry standard fonts will never be available in Google’s catalog because of licensing issues.

There is some very cool things you could do with this, I’ve purposely left out many technical details in order to give a more general overview of web fonts. Hopefully this has been enlightening and has sparked some creative ideas for cool new things you could do with this technology.

Happy Typing!