Anatomy of an @font-face Declaration

Bring Beautiful, Smooth CSS Animations to Life

by James Futhey — Posted in CSS / Animation on Tuesday, July 22, 2014

Tagged: Faux-Italics, @font-face, Mobile, Web Fonts, CSS, Fonts, Multiple Language Supprt

First Things First: The @font-face declaration (basic syntax)

Before we can call a font that doesn't exist on the local machine, we have to use @font-face to load it off the interwebs.

@font-face {
    font-family: 'Open Sans';
    font-style: normal;
    font-weight: 300;
    src: local('Open Sans Light'), local('OpenSans-Light'), url( format('woff');

You'll notice that several css properties are declared before the src: file is loaded. This is so that we can optionally load separate font files for multiple font weights and styles. Although the WOFF format can contain multiple weights and styles, the file we are using may not.

So, What happens when we call a web font?

When we call a remote web font, our browser searches for an EXACT MATCH among our @font-face declarations, including weight, face, and style, for EACH INDIVIDUAL GLYPH or language family / character encoding.

This is important to remember when working with other languages (Especially Asian languages). For example, if you are working with Chinese or Japanese, there are only a few fonts in existence, and invariably, they all have terrible Roman lettering for English text. Most contain a wide monospaced font. So, generally, you'll want to declare your English-language webfonts before declaring a set of Windows and Macintosh system fonts.

So, What happens when we match a font face but not a specific style or weight?

In short, all hell breaks loose. Font-rendering engines create weight and style variations by stretching and resizing existing fonts. In web typography, this is probably the biggest sin of them all: letting your rendering-engine decide how to handle your kerning, weight sizing, or letting it render all of your letters at a 15 degree angle and call them italic.

In the above image, you can see the original file, followed by a faux-italic version of the font, rendered by the system, followed by the tyopgrapher's intended italic styling. See a similar comparison in the following image:

Multiple source files can be defined in an @font-face declaration, and the last supported file type listed will be rendered by the user's browser. So, basically you're listing fonts in order from worst to best, and the browser will pick the best filetype it can work with. WOFF is supported by all current browsers, as of 2014. However, if you're ensuring compatibility with IE8 or Android 4.3 (Jelly Bean), you will want to first include an EOT file for IE, then a TTF or OTF font for Android 2+.

An interesting note is that you may want to purposefully force mobile users to fallback to system fonts when they are available, especially for body type, to save bandwidth and increase page rendering time.

For example, on older, underpowered Android devices, you can call 'Droid Sans' in your font-family declaration, after calling your webfonts but before calling your fallback Macintosh and Windows system fonts. Then, if your browser fails to load the WOFF or EOT file, it will check for the Android-specific system font before falling back to other system fonts. This way, you can reduce both page load and render time for large blocks of body text.

A careful understanding of how your fallback fonts cascade in different browsers can give you an enormous amount of control over the typography on your page.

category: CSS
subcategory: Web Fonts




James Futhey 


Apparition Theme
Thoughts, stories and ideas.