Paul Irish

Squeezing the best out of webfonts

Ustream Video. Follow along!
http://www.ustream.tv/recorded/4828154

Employing Custom Fonts

Paul Irish typography

Let me introduce you to the best way to do your @font-face definitions:

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot?') format('eot'), url('GraublauWeb.woff') format('woff'), url('GraublauWeb.ttf') format('truetype');
}

This is the Fontspring @font-face syntax. I'll circle back to why this is the best possible solution but let's first review the other techniques' weaknesses. Of course, the problem at the center of this is that IE needs an .eot font, and the other browsers must take a .ttf or .otf.

Okay, let's see what we got here…

Conditional comments (via)

<!--
@font-face{
  font-family:'Graublau Web';
  src: url('GraublauWeb.otf') format('opentype');
}
-->
 
<!--[if IE]>
<mce:style type="text/css" media="screen"><!
@font-face{
  font-family:'Graublau Web';
  src: url('GraublauWeb.eot');
}
-->

Ugh. Seriously? We'd have to drop that in every html file or have unique iefonts.css files. No fun. Also, ugly.

Double declarations (via)

@font-face{
  font-family:'Graublau Web';
  src: url('GraublauWeb.eot'); /* here you go, IE */
}
@font-face{
  font-family:'Graublau Web';
  src: url('GraublauWeb.otf'); /* everyone else take this */
}

The problem here is that, as Andrea points out, IE will actually download the .otf file. We can't have extra HTTP connections, so this is typically the solution:

@font-face {
  font-family: 'Graublau Web';
  src url('GraublauWeb.otf') format('opentype'); /* IE no comprende format()! */
}

Because after all, IE doesn't understand the format hint, right? It's true. But what really happens is that IE does a request for this filename:
GraublauWeb.otf')%20format('opentype

Oops, looks like someone forgot a ? in their regular expression! But hey, a 404 is a lot better than grabbing a file that's 20-100k. Let's kill that 404:

Mo’ Bulletproofer (via)

@font-face{
  font-family:'Graublau Web';
  src: url('GraublauWeb.eot'); /* here you go, IE */
}
@font-face{
  font-family:'Graublau Web';
  src: url(//:) format ('no404'), url('GraublauWeb.otf') format('opentype'); /* tricky! */
}

Richard Fink proposed this alternate syntax actually as a response to this post, but I've included it back here. The trick is to use url(//:), to prevent IE from 404'ing on the ttf/otf file. In his article he lists a few reasons why he prefers the semantics of this alternative. I understand the argument, but I don't like repeating myself, so I'm gonna keep trucking:

The local reference

@font-face {
  font-family: 'Graublau Web';
  src: url(GraublauWeb.eot);
  src: local('Graublau Web Regular'), url(GraublauWeb.otf) format('opentype');
}

Much more concise and clean. Here, non-IE browsers skip any .eot file and move on. IE will try to parse the second src value, but it can't understand the local() location nor the multiple locations, so it resorts to the EOT instead. Worth noting that IE will always dive to the last src:url() value to start, so this won't work.

src: url(GraublauWeb.eot);
src: url(GraublauWeb.otf); /* Yeah IE will only try this one. :( */

The other benefit.. if it just so happens that a user actually has your custom font installed, this'll save them the download. The one catch is that Safari on OS X will use only the Postscript name instead of the full font name; so when they differ, include both names:

Bulletproof @font-face

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('Graublau Web Regular'), local('Graublau Web'),
         url('GraublauWeb.otf') format('opentype');
}

Bulletproof @font-face: Smiley variation

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('?'),
         url('GraublauWeb.otf') format('opentype');
}

Added 2010.02.04: There has been concern over specifying local font names. The primary reason is that you cede control to the user's machine, potentially showing a locally installed font instead of the one you want to serve. While that will load faster, there's a very small chance the file could be wrong.

To account for this gotcha, I've specified a local font name of ?. Yes, it's a smiley face. The OpenType spec indicates any two-byte unicode characters won't work in a font name on Mac at all, so that lessens the likelihood that someone actually released a font with such a name. This technique is recommended if you think a locally installed version of this font is not in your best interest.
Added 2010.05.05: The smiley variation is my new recommendation. ← Click through to read why.

The Fontspring @font-face syntax

Ethan (the same guy behind Font Squirrel), figured out a trick to make it work everywhere (including IE6, Android, iOS) including all the bugs the above tricks work around.. It's called the Fontspring @font-face syntax. It goes a little something like this:

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot?') format('eot'), url('GraublauWeb.woff') format('woff'), url('GraublauWeb.ttf') format('truetype');
}

Remember that 404 problem from above? The question mark solves that. That's about it.

Also worth noting, the correct format type for an .eot is 'embedded-opentype'. But if you change it to anything invalid, IE9 will prioritize the WOFF file above the EOT, which is good! So we use 'eot'.. but this could just as easily be 'ie9-give-me-the-woff-instead'.

Demo

I've added a test page with a few syntax variants here for crossbrowser testing

Additional notes and gotchas:

• Including a font-variant property inside the definition will cause it to not work in Safari (4.0.3 tested) as well as IE 6-8. (Thanks Sid)
• Including a font-style property the definition is safe and the definition will still succeed with all browsers, however IE ignore what you define it as.But if you want a bold or italic style of a font to display, you'll need to make two definitions. Read the It Takes Two, Baby section on Nice Web Type's how to use css font face article
• Opera will fail if you do not use quotes (single or double) in your local() font name. So: local('Use Quotes'). I've filed this bug with Opera as it's a spec violation. Thank you to Scott Kimler and Richard Fink for helping with the tireless research on Opera's quirks.
• Safari permission error? Some people experience a dialog asking for permission to use a local font. This only happens in webkit. [screenshot]
  • Thibault Bardat-Bujoli indicated that this behavior is due to Linotype FontExplorer X. For any font added but not 'activated', it will intercept requests to use it. You can disable this behavior within the FontExplorer UI [jpg]. I have heard no reports of this behavior on machines lacking FontExplorer
  • More on my @font-face gotchas post
• Chrome? A few rumors are going around that a Chrome beta or dev build has @font-face support. There is no install of Chrome that has @font-face enabled by default [actually, it's in dev builds now!], however you can enable it in Chrome 3 with an executable switch. I'm keeping this page on @font-face and Google CHrome up to date with all the details.
• You can feed FF, Opera and Safari a truetype but specify it as format('opentype') and it's just fine. So for all intents and purposes, if your font is opentype or truetype, the format hint is optional.
• The font name that specified in your @font-face declaration cannot exceed 31 characters in length. IE will fail on anything larger.
• I first found this bulletproof technique in use by Mark Pilgrim at http://diveintohtml5.org. My hat is off to you, good sir.

SVG? WOFF?

Since Google Chrome won't have typical @font-face support until version 4, we can snag it early by serving it SVG fonts. WOFF is a new format that is officially supported in Firefox 3.6 Can we integrate those into this syntax? Definitely.

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('?'),
    url("GraublauWeb.woff") format("woff"),
    url("GraublauWeb.otf") format("opentype"),
    url("GraublauWeb.svg#grablau") format("svg");
}

The order of those is deliberate and discussed in the comments here. Hat tip to Snook for being the first to drag SVG into the party. Font Squirrel and Nice Web Type have also been very thoughtful in their work.

Android :/

Bulletproof smiley doesn't work in Android 2.2-2.3 (which supports @font-face, but not the local() definition). Personally, I'm okay with that because I don't want to wait another 5 seconds for 100kb of fonts to load before I actually see text (thanks webkit FOUT bug).

But hey, some people might prefer webfonts over quick loads.. and for you, there is a pretty okay fix to that:

@font-face {
  font-family: 'Graublau Web';
  src: url('GraublauWeb.eot');
  src: local('?'),
    url("GraublauWeb.woff") format("woff"),
    url("GraublauWeb.otf") format("opentype"),
    url("GraublauWeb.svg#grablau") format("svg");
  }  
@media screen and (max-device-width: 480px) {
  @font-face {
    font-family: "Graublau Web";
    src: url("GraublauWeb.woff") format("woff"),
    url("GraublauWeb.otf") format("opentype"),
    url("GraublauWeb.svg#grablau") format("svg"); 
}}

For mobile we redeclare the @font-face declaration without the local() guy. We'll also give it the woff, opentype and svg, even though no mobile devices support WOFF so far. Also for this media query to succeed in Android Webkit, you're gonna want a viewport meta tag.

 <meta name="viewport" content="width=device-width, initial-scale=1.0">

That'll do. :)

I'm confused and lazy. Help?

Want to absorb the benefits of this article instantly? Use Font Squirrel's awesome @font-face generator. It does all of this for you, and more. If you're less lazy, read through Nice Web Type's How To for all the deets.

Paul Irish front-end development, typography

As I'm piecing together a very comprehensive solution for using custom typefaces online, one of the crucial aspects is determining what browsers support @font-face.

My requirements for this detection were:

• No browser userAgent sniffing
• No extra HTTP request required
• The test must be synchronous, no race conditions or HTTP requests
• Must be performant with a small footprint, natch
• Results should match the latest research on compatibility

I quickly tried:

!!window.CSSFontFaceRule

This test works great in FF2+, Safari and Opera. But it fails in IE (bug surprise) and Chrome gives a false positive.

The code

What follows is the best test for @font-face support I have found:

 
/*!
 * isFontFaceSupported - v0.9 - 12/19/2009
 * http://paulirish.com/2009/font-face-feature-detection/
 * 
 * Copyright (c) 2009 Paul Irish
 * MIT license
 */
 
var isFontFaceSupported = (function(){
 
 
    var fontret,
        fontfaceCheckDelay = 100;
 
		// IE supports EOT and has had EOT support since IE 5.
		// This is a proprietary standard (ATOW) and thus this off-spec,
		// proprietary test for it is acceptable. 
    if (!(!/*@cc_on@if(@_jscript_version>=5)!@end@*/0)) fontret = true;
 
    else {
 
    // Create variables for dedicated @font-face test
      var doc = document, docElement = doc.documentElement, 
          st  = doc.createElement('style'),
          spn = doc.createElement('span'),
          wid, nwid, body = doc.body,
          callback, isCallbackCalled;
 
      // The following is a font, only containing the - character. Thanks Ethan Dunham.
      st.textContent = "@font-face{font-family:testfont;src:url(data:font/opentype;base64,T1RUTwALAIAAAwAwQ0ZGIMA92IQAAAVAAAAAyUZGVE1VeVesAAAGLAAAABxHREVGADAABAAABgwAAAAgT1MvMlBHT5sAAAEgAAAAYGNtYXAATQPNAAAD1AAAAUpoZWFk8QMKmwAAALwAAAA2aGhlYQS/BDgAAAD0AAAAJGhtdHgHKQAAAAAGSAAAAAxtYXhwAANQAAAAARgAAAAGbmFtZR8kCUMAAAGAAAACUnBvc3T/uAAyAAAFIAAAACAAAQAAAAEAQVTDUm9fDzz1AAsD6AAAAADHUuOGAAAAAMdS44YAAADzAz8BdgAAAAgAAgAAAAAAAAABAAABdgDzAAkDQQAAAAADPwABAAAAAAAAAAAAAAAAAAAAAwAAUAAAAwAAAAICmgGQAAUAAAK8AooAAACMArwCigAAAd0AMgD6AAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAEZIRAAAQAAgAC0C7v8GAAABdv8NAAAAAQAAAAAAAAAAACAAIAABAAAAFAD2AAEAAAAAAAAAPAB6AAEAAAAAAAEAAgC9AAEAAAAAAAIABwDQAAEAAAAAAAMAEQD8AAEAAAAAAAQAAwEWAAEAAAAAAAUABQEmAAEAAAAAAAYAAgEyAAEAAAAAAA0AAQE5AAEAAAAAABAAAgFBAAEAAAAAABEABwFUAAMAAQQJAAAAeAAAAAMAAQQJAAEABAC3AAMAAQQJAAIADgDAAAMAAQQJAAMAIgDYAAMAAQQJAAQABgEOAAMAAQQJAAUACgEaAAMAAQQJAAYABAEsAAMAAQQJAA0AAgE1AAMAAQQJABAABAE7AAMAAQQJABEADgFEAEcAZQBuAGUAcgBhAHQAZQBkACAAaQBuACAAMgAwADAAOQAgAGIAeQAgAEYAbwBuAHQATABhAGIAIABTAHQAdQBkAGkAbwAuACAAQwBvAHAAeQByAGkAZwBoAHQAIABpAG4AZgBvACAAcABlAG4AZABpAG4AZwAuAABHZW5lcmF0ZWQgaW4gMjAwOSBieSBGb250TGFiIFN0dWRpby4gQ29weXJpZ2h0IGluZm8gcGVuZGluZy4AAFAASQAAUEkAAFIAZQBnAHUAbABhAHIAAFJlZ3VsYXIAAEYATwBOAFQATABBAEIAOgBPAFQARgBFAFgAUABPAFIAVAAARk9OVExBQjpPVEZFWFBPUlQAAFAASQAgAABQSSAAADEALgAwADAAMAAAMS4wMDAAAFAASQAAUEkAACAAACAAAFAASQAAUEkAAFIAZQBnAHUAbABhAHIAAFJlZ3VsYXIAAAAAAAADAAAAAwAAABwAAQAAAAAARAADAAEAAAAcAAQAKAAAAAYABAABAAIAIAAt//8AAAAgAC3////h/9UAAQAAAAAAAAAAAQYAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAA/7UAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAQAEBAABAQEDUEkAAQIAAQAu+BAA+BsB+BwC+B0D+BgEWQwDi/eH+dP4CgUcAIwPHAAAEBwAkREcAB4cAKsSAAMCAAEAPQA/AEFHZW5lcmF0ZWQgaW4gMjAwOSBieSBGb250TGFiIFN0dWRpby4gQ29weXJpZ2h0IGluZm8gcGVuZGluZy5QSVBJAAAAAAEADgADAQECAxQODvb3h/cXAfeHBPnT9xf90wYO+IgU+WoVHgoDliX/DAmLDAr3Fwr3FwwMHgoG/wwSAAAAAAEAAAAOAAAAGAAAAAAAAgABAAEAAgABAAQAAAACAAAAAAABAAAAAMbULpkAAAAAx1KUiQAAAADHUpSJAfQAAAH0AAADQQAA)}";
      doc.getElementsByTagName('head')[0].appendChild(st);
 
 
      spn.setAttribute('style','font:99px _,serif;position:absolute;visibility:hidden'); 
 
      if  (!body){
        body = docElement.appendChild(doc.createElement('fontface'));
      } 
 
      // the data-uri'd font only has the - character
      spn.innerHTML = '-------';
      spn.id        = 'fonttest';
 
      body.appendChild(spn);
      wid = spn.offsetWidth;
 
      spn.style.font = '99px testfont,_,serif';
 
      // needed for the CSSFontFaceRule false positives (ff3, chrome, op9)
      fontret = wid !== spn.offsetWidth;
 
      var delayedCheck = function(){
        if (isCallbackCalled) return;
        fontret = wid !== spn.offsetWidth;
        callback && (isCallbackCalled = true) && callback(fontret);
      }
 
      addEventListener('load',delayedCheck,false);
      setTimeout(delayedCheck,fontfaceCheckDelay);
    }
 
    function ret(){  return fontret || wid !== spn.offsetWidth; };
 
    // allow for a callback
    ret.ready = function(fn){
      (isCallbackCalled || fontret) ? fn(fontret) : (callback = fn);
    }  
 
    return ret;
})();

Download from github

The latest is always at: http://github.com/paulirish/font-face-detect
isFontFaceSupported.js Uncompressed – 4.3k
isFontFaceSupported.min.js Compressed – 3.1k

Usage

isFontFaceSupported() // will return a boolean indicating support
 
// you can also use with a callback,
//  it will be called 100ms later which is adaquate for Gecko and Webkit to properly use the data-uri'd font.
isFontFaceSupprted.ready(function(bool){
  // bool is a boolean that indicates support
});

Sorry. :(

You'll spot the IE conditional compilation in there. I don't like it either, but I'm unaware of any other workable approach (that doesn't pull in an .eot) to test for @font-face support. If you have an idea, please share it!

On the approach

I first use the Web Font Optimizer to subset a truetype font to only contain the period (.) character (2.2k file!), then send it through a data URI converter, then chuck it into a style tag. I test the width of a span of text without the custom font, and then again with the custom font. If the values are different, we can assume @font-face is supported and works.

With a trip through the YUI Compressor, the script is 3.5k3.1k. If you have any ideas on bringing that figure down, I'd love to hear 'em.

Great! Any disadvantages?

Yeah there's one big one. Both Gecko and Webkit load in a data-uri font asynchronously, so the test may give a false negative if you call isFontFaceSupported() immediately afterwards:

<script src="isFontFaceSupported.min.js"></script>
<script>
  if (isFontFaceSupported()) ... // this may report a false negative.
 // that's why we have the isFontFaceSupported.ready() callback mechanism

I'm not terribly happy with this asynchronous delay, so I've written an alternative that uses browser userAgent sniffing. This practice is not recommended and is not terribly future-proof, but it's the only synchronous solution available.

isFontFaceSupported() – sniffing variant

/*!
 * isFontFaceSupported - Sniff variant - v0.9 - 12/19/2009
 * http://paulirish.com/2009/font-face-feature-detection/
 * 
 * Copyright (c) 2009 Paul Irish
 * MIT license
 */
 
/* Browser sniffing is bad. You should use feature detection.
   Sadly the only feature detect for @font-face is 
   asynchronous. So for those that *need* a synchronous solution,
   here is a sniff-based result:
*/
 
var isFontFaceSupported = function(){
 
  var ua = navigator.userAgent, parsed;
 
  if (/*@cc_on@if(@_jscript_version>=5)!@end@*/0) 
      return true;
  if (parsed = ua.match(/Chrome\/(\d+\.\d+\.\d+\.\d+)/))
      return parsed[1] >= '4.0.249.4';
  if ((parsed = ua.match(/Safari\/(\d+\.\d+)/)) && !/iPhone/.test(ua))
      return parsed[1] >= '525.13';
  if (/Opera/.test({}.toString.call(window.opera)))
      return opera.version() >= '10.00';
  if (parsed = ua.match(/rv:(\d+\.\d+\.\d+)[^b].*Gecko\//))
      return parsed[1] >= '1.9.1';    
 
  return false;
 
}

This guy is also on github

var isFontFaceSupported = (function(){  
var 
sheet, doc = document,
head = doc.head || doc.getElementsByTagName('head')[0] || docElement,
style = doc.createElement("style"),
impl = doc.implementation || { hasFeature: function() { return false; } };
 
style.type = 'text/css';
head.insertBefore(style, head.firstChild);
sheet = style.sheet || style.styleSheet;
 
var supportAtRule = impl.hasFeature('CSS2', '') ?
        function(rule) {
            if (!(sheet && rule)) return false;
            var result = false;
            try {
                sheet.insertRule(rule, 0);
                result = !(/unknown/i).test(sheet.cssRules[0].cssText);
                sheet.deleteRule(sheet.cssRules.length - 1);
            } catch(e) { }
            return result;
        } :
        function(rule) {
            if (!(sheet && rule)) return false;
            sheet.cssText = rule;
 
            return sheet.cssText.length !== 0 && !(/unknown/i).test(sheet.cssText) &&
              sheet.cssText
                    .replace(/\r+|\n+/g, '')
                    .indexOf(rule.split(' ')[0]) === 0;
        };
 
return supportAtRule('@font-face { font-family: "font"; src: "font.ttf"; }');
})();

Paul Irish front-end development, javascript, typography

In the current discussions around fonts on the web, there is much confusion between the techniques. Most seem to think that TypeKit and .webfont are our only options. They are not, but the rest of the landscape is quite busy.

Things have been moving very quickly in the last three weeks, so let me break it down like this:

• Webfont services: TypeKit, fontdeck, Typotheque
• Proposals: EOT-Lite, .webfont, ZOT, webOTF
• Implemented standards: @font-face using EOT and TTF
• JavaScript-based font solutions: sIFR, Facelift, Cufón

The commercial webfont services players

While many have considered TypeKit as an alternative to .webfont, it's just a smart implementation of CSS and JavaScript along with a shop and licensing model. I agree with Pablo Impallari who commented:

You don’t need typekit, .webfont or any other solution. You can start using real fonts on the web right now.

Typekit makes a somewhat complicated implementation drop-dead easy, but if you've used sIFR before, than I'm confident you can handle this on your own.

The licensing legwork that TypeKit is doing is a significant value-add and may be worth it for people who don't want to deal directly with font resellers. I'm quite interested in how the smart folks at Clearleft expect to differentiate their competing service, fontdeck.

Typotheque and Kernest are also new entrants to watch, both created by font shops. Both seem to only license their own foundries' typefaces, so their library size may end up being quite small, but I can say right now Typotheque's offering looks strong.

At the same time, we've had web font services already: Fontburner and Flir Premium, but they never really gained popularity, so I'm surprised people expect such a different outcome from these new players.

The EOT-Lite and .webfont proposals

The general complaint from the type community around non-EOT @font-face is that the naked font is so accessible, anyone could trivially take it off a webserver and install it on their machine. These two proposals offer a “garden fence” approach to protection; it's still quite easy to get inside and snag the font, but it's harder than if there were no protection at all.

.webfont, the format proposed by Tal Leming and Erik van Blokland is a great compromise solution: basically a zip file containing both an xml file of metadata and the font. While it uses the same css @font-face syntax, and everyone seems to love it, having it work in all browsers is at least three years off.

EOT-Lite, on the other hand, seems to be covered much less in roundups to date. The basic idea is that it's the same as EOT but without the two major complaints of the format: domain binding and MTX compression. (Interesting as, the compression's patent owner is offering to free it up.)

The huge plus of EOT-Lite is that the format works, right now, in IE4-IE8. Adobe, Monotype, Microsoft and a cadre of type shops support it. Perhaps surprising for some, Mozilla is also quite involved in the EOT-Lite discussion, not only helping to define the spec, but also making a test build of Firefox that handles the new format.

ZOT is a new format proposed by Mozilla; essentially TTF with compression. It's well considered, but as .webfont comes with the same advantages and already has a wave of support, I think ZOT is best left as an academic discussion. Oh, and Berlow's OpenType permissions table – which would have been a great idea to have in 2000, but not now.

Update 2009.08.10: .webfont and ZOT merged their proposals. It's now called WebOTF.

The @font-face standard

By my calculations, the current implementation (using EOT or TTF/OTF) covers ~70% of users. When Firefox 3.0 users upgrade to 3.5 that figure will increase to ~90% of users (I bet we'll see that within six months). Things still do visually look a little different across browser implementations, but they currently work cross-browser and with fixes like forcing Cleartype on for web fonts in Firefox, render quality is improving steadily.

/* it's this easy: */
@font-face {
  font-family: 'Gentium';
  src: url(Gentium.eot); /* EOT for IE */
}
@font-face {
  font-family: 'Gentium';
  /* IE ignores this one because of the format value */
  src: url(Gentium.ttf) format("opentype");
}
h1,h2,h3 { font-family: 'Gentium', Tahoma, sans-serif;

I generally side with the concerns of type foundries here, rather than the Fuck The Foundries crowd. I want myself and other designers to have access to the best of typography, but understand the fonts used for Firefox/Webkit are a little too naked at this point. While we're waiting for the rest of this to pan out we may see a new market of type designers that are comfortable with naked fonts (like David B?ezina), but I'm skeptical about the efficacy of that.

JavaScript-based custom font solutions

We've had sIFR for nearly 5 years and I'm glad we have, but we now have better options. After significant research I think Cufón is the best library in this space; it's small, clever, and very performant. However, many foundries aren't ready to license their typefaces for use with Cufon. Facelift is a great alternative here, as it doesn't expose the font data to the browser (instead generating PNGs via PHP), thus very licensing-friendly.

These libraries will be useful in bringing custom fonts to older browsers (currently: Firefox 3.0, Chrome, and Opera 9), but still lack flexibility when it comes to rtl languages.

It's also possible that they won't be treated only as a fallback solution. If foundries remain unwilling to license for the naked @font-face implementation in Firefox and Webkit, we may have no choice but to use Cufón while we're waiting for these browsers to adopt EOT-Lite or .webfont. In fact, Monotype's web embedding EULA currently allows use with siFR and Cufón, as long as there is domain-binding.

Conclusions

I don't think webfont services are the future, but I do think the landscape is hairy enough now to convince web developers to take the easy route by relying on a TypeKit or Fontdeck for their custom type. Taking advantage of the best techniques available isn't insurmountable without a hosted webfont service, and I think we'll see developers going it alone with their own implementations and licensing directly with the font resellers.

I believe EOT-Lite is the right direction for webfonts right now. It already works in the most stubborn browser, and since Firefox just released a test build with support for EOT-Lite, it's looking more reasonable than ever. It's also quite interesting that after the months of debate at the W3C surrounding Microsoft's proposal of making EOT the standard, it took quite some time for the sensible proposal of EOT-Lite to emerge. I guess both sides had to soften a little. :)

Paul Irish front-end development, typography

Presentation

Links

@font-face

www.webfonts.info/wiki/index.php?title=Fonts_available_for_@font-face_embedding
del.icio.us/paul.irish/fontface

sIFR

novemberborn.net/sifr3
designintellection.com/this-is-how-you-get-sifr-to-work/
css-tricks.com/new-screencast-how-to-use-sifr-3/
jQuery sIFR plugin
www.sifrgenerator.com
www.sifrvault.com

Facelift

bit.ly/facelift
facelift.mawhorter.net/doc/plugins-quickeffects

typeface.js

bit.ly/typefacejs
www.madasplayground.com/fonts/  

Cufón

bit.ly/cufon
net.tutsplus.com/videos/screencasts/the-easiest-way-to-use-any-font-you-wish/
www.cameronmoll.com/archives/2009/03/cufon_font_embedding/  
cameronmoll.com/articles/cufon/calgary.html

Drupal modules

Drupal sIFR
Drupal Facelift
Drupal Cufon

Other evaluations of rich typography options

Typography for the web – NY Web Standards Meetup
Cufon vs sIFR vs FLIR
Cufon vs Typeface.js – Which one is better?

Other

List of foundries that license for web embedding

Paul Irish typography