Elliot Jay Stocks logo by Emma Luczyn

Font-weight in the age of web fonts

Article illustration for Font-weight in the age of web fonts

If you’ve seen me speak at a conference recently, or we’ve chatting about the web whilst sharing a pint, you might have noticed a pattern emerging whenever I talk about web fonts: as keen as I am to celebrate them as the coming of true typographic nirvana, I’ve become increasingly careful to document their shortcomings, too. As I’m saying at all of my talks this year, with great power comes great responsibility.

So it is that my attention has been caught by the humble CSS property font-weight . When we only had to worry about core system fonts and their meagre weight variations of ‘normal’ and ‘bold’, the font-weight definition was barely worthy of consideration. But now that we have decent web font support in our browsers and fantastic services such as Typekit, Fontdeck, et al adorning our sites us with a multitude of beautiful typefaces, the once-simple property requires some more thorough consideration.

Because so many professional quality web fonts come in a variety of weights, it now makes much more sense to use the numerical scale than it did when we only had to deal with ‘normal’ (400) and ‘bold’ (600). Typically, a family’s weights can be mapped to these values:

100: Ultra Light
200: Thin
300: Light
400: Regular
500: Semi Bold
600: Bold
700: Extra Bold
800: Heavy
900: Ultra Heavy

Note the keyword, there: typically. The reality, sadly, is that many fonts just don’t conform to this pattern, like when a family has a multitude of weights, or where their own definitions don’t necessarily conform to the standard scale. So that’s problem number one.

The bigger issue

Problem number two is significantly bigger than the first. Consider _ FF Enzo_, which doesn’t have a 400 (or even 500) weight. In some circumstances, its Light (300) weight might perhaps be a little too thin for small body type, so let’s use the 600 weight instead. Ah, that looks okay.

But it’s not okay! Because if that font can’t be displayed and we fallback to something else, that fallback font will render at its 600 weight; in other words: bold. There’s a fair amount we can get away with when we resign ourselves to fallback plans, but all-bold body text is about as desirable as Comic Sans on a gravestone.

Plus, even if we have a typeface whose ‘regular’ weight is mapped to 400, if the typeface itself happens to be unusually light or heavy, then we still have the same problem: using lighter or heavier numerical values to adapt will result in incorrect fallback weights. Maybe that’s fine if we’re talking about display sizes, but not with body type.

A workaround?

There’s a way around this and it’s the method FontsLive use in the CSS they generate for their users: you declare each weight individually rather than the entire family. Their code looks a bit like this:

{ font-family: 'FamilyName Light', 'FallbackFamily', serif; font-weight: normal; }
{ font-family: 'FamilyName Medium, 'FallbackFamily', serif; font-weight: normal; }
{ font-family: 'FamilyName Bold', 'FallbackFamily', serif; font-weight: bold; }
{ font-family: 'FamilyName Black', 'FallbackFamily', serif; font-weight: bold; }

That works well, in that you can neatly map the more extreme weights (light, thin, heavy, etc.) into the good-for-fallback classifications of ‘normal’ and ‘bold’. The downside, as Rich Rutter noted back at the beginning of 2009, is that you have to declare every weight individually and you don’t get to make use of the numerical weight values built directly into CSS.

Fontdeck take a similar approach to FontsLive and specify each weight in the font-family declaration, but rather than group each one into either ‘normal’ or ‘bold’, they also include the correct 100 – 900 values.

Recently, Typekit improved support for font-weight in IE6, 7, and 8 by allowing the designer to add additional family declarations to their stylesheets if they want to support multiple weights in IE. This is good news for those on IE, although it’s worth noting that the workaround is effectively the same as declaring each weight as a font-family, as in the FontsLive and Fontdeck examples above.

Better weight declarations

The long and short of it is this: the best approach has yet to be found. All of the current methods are solutions, but — like many things in the world of web design — only for certain scenarios. What we need is consistency… but who is responsible for the inconsistency in the first place? Not web designers or font delivery services. Some might suggest browser vendors, who have the power to introduce new CSS features. Others might suggest the type foundries themselves, but should they be forced to pigeonhole a typeface’s weights to fit such a limited scale?

The numerical system we use for font-weight in CSS is taken from the TrueType / OpenType system that in itself appears to have been derived from the Linotype numbering system of nine steps, which differs slightly from the ten-step version designed by Adrian Frutiger. However, neither system is robust enough to describe the fourteen weights documented by Jon Tan.

Is it time to create a new system that can be used by CSS?

At this point, I would usually attempt to offer a conclusion. What I want to do instead is open it up the floor: I’d love to hear suggestions from those who are passionate about web typography: web designers, web developers, type foundries, font delivery networks. What is the answer? And if there isn’t one, how do we collectively go about making one?

Next post

Three things

Previous post

The Email Charter