The @font-face CSS rule has been around since CSS2 (but subsequently absent in CSS 2.1). It was even supported partially by Internet Explorer 4 (no, really)! So what's it doing here, when we're supposed to be talking about CSS3?

Well, as it turns out, @font-face has been re-introduced for the CSS3 Fonts module (http://www.w3.org/TR/css3-fonts). Due to the historic legal quagmire of using fonts on the web, it's only recently started to gain serious traction as the de facto solution for web typography. There's also the issue of the varying font formats and implementations from different vendors. For example, the Embedded OpenType (EOT) font was Internet Explorer's (and not anyone else's) preferred choice of font format. Others favor the more common place TrueType (TTF), whilst there is also Scalable Vector Graphics (SVG) and Web Open Font Format (WOFF). When it comes to using @font-face for your web typography, there is both good news and bad. First the bad…

Until a single universal format wins out, it's necessary to serve multiple versions of the same font to cover the different browser implementations. Much as there are competing video formats, we also need a single font format for the web to emerge victorious before dropping support for the others.

However, the good news is that adding custom fonts for every browser is now easy. Let's do it!

Let's get the And the winner isn't... site typography licked into shape with the @font-face CSS rule.

First we need some fonts. There are now a number of great sources for web fonts; both free and paid. My personal favorite is Font Squirrel (www.fontsquirrel.com) although Google also offers free web fonts, ultimately served with the @font-face rule (www.google.com/webfonts). There are also great, paid services from Typekit (www.typekit.com) and Font Deck (www.fontdeck.com).

As chance would have it the fonts used in my composite are all available free from Font Squirrel (I know, I'm a cheapskate!). They are Bebas Neue, Bitstream Vera Sans and Collaborate Thin. Having downloaded the relevant @font-face kit for each font from Font Squirrel a look inside the ZIP file of each reveals the font itself in various formats (WOFF, TTF, EOT , and SVG) plus a stylesheet.css file containing a font stack for the font needed. For example, the rule for Bebas Neue is as follows:

@font-face {
    font-family: 'BebasNeueRegular';
    src: url('BebasNeue-webfont.eot'),
    src: url('BebasNeue-webfont.eot?#iefix') format('embedded-opentype'),
         url('BebasNeue-webfont.woff') format('woff'),
         url('BebasNeue-webfont.ttf') format('truetype'),
         url('BebasNeue-webfont.svg#BebasNeueRegular') format('svg'),
    font-weight: normal;
    font-style: normal;

}

Much like the way vendor prefixes work, the browser will apply styles from that list of properties (with the lower properties, if applicable, taking precedence) and ignore ones it doesn't understand. That way, no matter what the browser, there should be a font that it can use.

Now, although this block of code is great for fans of copy and paste, it's important to pay attention to the paths the fonts are stored in. For example, I tend to copy the fonts from the ZIP file and store them in a folder inventively called fonts on the same level as my css folder. Therefore, as I'm usually copying this font stack rule into my main stylesheet, I need to amend the paths. So, my rule becomes:

@font-face {
    font-family: 'BebasNeueRegular';
    src: url('../fonts/BebasNeue-webfont.eot'),
    src: url('../fonts/BebasNeue-webfont.eot?#iefix') format('embedded-opentype'),
         url('../fonts/BebasNeue-webfont.woff') format('woff'),
         url('../fonts/BebasNeue-webfont.ttf') format('truetype'),
         url('../fonts/BebasNeue-webfont.svg#BebasNeueRegular') format('svg'),
    font-weight: normal;
    font-style: normal;

}

It's then just a case of setting the correct font and weight (if needed) for the relevant style rule. In this case, I want to amend the navigation links to use the new Bebas Neue font:

nav ul li a { 
  height: 42px; 
  line-height: 42px; 
  text-decoration: none; 
  text-transform: uppercase; 
  font-family: 'BebasNeueRegular'; 
  font-size: 1.875em; /*30 ÷ 16 */  
  color: black; 
}

And here is how the navigation bar now looks in the browser:

When replacing fonts you'll typically need to amend the font sizing. However, having put the existing font size calculation in a comment to the side, it's easy to amend accordingly. An added bonus is that, if the composite uses the same fonts you are using in the code, you can plug the sizes in direct from the composite file. For example, my composite shows the "EVERY YEAR…" text as 102 px, so using the tried and trusted target ÷ context = result technique I can convert this value to ems:

#content h1 { 
  font-family: Arial, Helvetica, Verdana, sans-serif; 
  text-transform: uppercase; 
  font-family: 'BebasNeueRegular';
  font-size: 6.375em;  /* 102 ÷ 16 */
} 

Once I've amended the font-family and font-size declarations for all relevant rules, the front page now looks like the following in Google Chrome (using the WOFF font format):

The design still isn't perfect but the typography now perfectly mirrors that of our original composite. For comparison, here's how it's looking on the iPad 2 (which supports TTF fonts form version iOS 4.2 onwards):