Elliot Jay Stocks is a designer, speaker, and author. He is the Creative Director of Adobe Typekit, the founder of typography magazine 8 Faces, one half of Viewport Industries, and an electronic musician.

Font-weight in the age of web fonts

Posted on 07 July 2011 25 comments

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?

25 comments

  1. Jason Pamental

    Jason Pamental

    07 July 2011 @ 03:50PM #

    Hi Elliot -

    I’m not certain that you need to deal with standardizing font weights/number mapping and all that so long as you are using the Google Web Fonts loader. That lets you craft CSS for your fallback fonts to better match size, line-height and and letter-spacing so that your text has a minimal amount of reflow when the web fonts are loading (or fail to load entirely). It’s not all that much extra work and it makes the most of ‘loosely coupled systems’ that’s sort of the hallmark of web standards-based design (at least I think so). (I’ve been working on an example & article about that very topic)

    Jason

  2. Tammy Hart

    Tammy Hart

    07 July 2011 @ 03:53PM #

    I have often wondered about this problem, but haven’t really done much research. I preer to use free fonts like Google webfonts or those found in kits at FontSquirrel. The kit generoator declares every weight individually and then I find myself adding css declarations such as

    b, strong { font-family:‘FamilyNameBold’, etc.}
    and
    i, em { font-family:‘FamilyNameItalic’, etc. }

    Is this what we should be doing?

  3. Luke Connolly

    Luke Connolly

    07 July 2011 @ 04:24PM #

    Hey Elliot,

    This is something I have started to notice in my work with web fonts. I’m very much intrigued by Jason’s post above, but I also wish for something better (ideally, purely CSS-based).

    In my mind, it would be really nice to be able to define a font stack with individual styles/weights for each family… so something like

    font: 12px/16px “EmbeddedFont” bold, 14px/16px “Fallbackfont” regular, 12px/16px sans-serif;

    It just seems a shame to lose the elegance of stacks.

    Thanks for posting this, I look forward to more insight from you and your readers.

  4. Van

    Van

    07 July 2011 @ 04:26PM #

    I think closer collaboration between designers and front end devs is needed on font display issues. The designer should always manhandle and test font families and fall backs themselves and coordinate findings with whomever keeps the code.

    Secondly, if there is a service like Typekit being used, that service should suggest default fallbacks for you based on your style and weight choices. I was kind of shocked when I first used Typekit that all I had was sans and serif supplied as fallbacks. I thought it would wrap the whole process up for me in that CSS Stack area.

    My third thought: Holy cow I like Comic Sans on a gravestone, I think its finally found a home in the real world!

  5. James Patrick Gibson

    James Patrick Gibson

    07 July 2011 @ 04:28PM #

    Great discussion.

    I imagine that it really boils down to the designer to use due diligence when declaring fonts for specific uses on a site.

    Which brings up an interesting dilemma, because many designers take a very cascading approach to type, and just sort of add on the bits and pieces, that need emphasis, bolding or otherwise.

    Others (similar to what I do) have had complete beautiful CSS structures completely fall apart as soon as you introduce something like an Ultra Light, because the x-heights, tracking, line-heights etc. always vary, so having a boilerplate to start from, proves more frustrating, even though you are technically adhering to a CSS best practice.

    I think a good approach, is to be precise about what you use various weights for. Nobody in their right mind should be using lights or ultra-lights in anything less than a display or headline capacity, so most of the fallbacks won’t be “awesome” but at least they’ll look acceptable.

    I’d imagine that in body, caption and subheads sizes, many of the fallbacks start looking like garbage.

    I dig the approach Jon Korpi takes on the Less Framework: http://lessframework.com/
    Where you can start with a certain characteristic, x-height, ascender/decender qualities, and work up from there. (I.e. Starting from Palatino as a base – 17/24) and start setting a nice foundation, that you can “progressively-enhance” (I hate that term) with variations of weight, and adding your @font-face awesomeness to your heads, subs, captions and such.

    You won’t get the most elegantly cascading CSS that way, but at least when you fallback, it doesn’t look completely wrong.

    Although, what should really be the answer is a revision of CSS to accept fallbacks, in the same vein that we do RGB, RGBa for colors and such. Ignore it, if you don’t support it.

    That would be rad.

  6. Chris Armstrong

    Chris Armstrong

    07 July 2011 @ 04:23PM #

    We’ve been thinking about this for Typecast, particularly around the fallback issue. I wonder would webfont loader (http://code.google.com/apis/webfonts/docs/webfont_loader.html) be a useful solution in the meantime? That way you can set the fallback weight to be 400 if FF Enzo hasn’t loaded.

    Personally, I’d quite like it if you could declare font-weight as part of font-family, something like

    font-family: “FF Enzo” 600, “Arial” 400

  7. Pete

    Pete

    07 July 2011 @ 04:37PM #

    I’ve only one real thought on this, which is probably highly idealistic and with quite a few draw backs.

    In a way it might be a nice solution to map a pre-defined weight scale to a particular weight of defined non-system font, and let it fall back to something that’s not defined in the same manner. For example, something like:

    font-family: {’elliotjayfontface’, Georgia, serif; }
    font-weight: { 600; }
    font-fallback-weight {500=bold;}

    I’ve totally invented that last bit, but something along those lines might be useful to define where in the spectrum the fall back option would default to.

  8. Mandy

    Mandy

    07 July 2011 @ 04:44PM #

    Regarding the fallback scenario, if you use the web font loader (which is baked into Typekit), you can craft unique styles for fallback fonts. This is useful not only when you are using non-standard weights, but when you are using a font that is larger or smaller than your fallback and need to specify different sizes. (A simple case of this is when you are using a script or condensed font for a heading at a very large size, but the fallback web safe font needs to be set much smaller to fit appropriately.)

    Essentially, that looks like this:

    .wf-inactive h1 {

    • fallback styles *
      }

    .wf-active h1 {

    • web font styles *
      }

    You can also use the web font loader’s font events for more control over how fonts load: controlling the FOUT in FIrefox, or fading in text when the font finishes loading, for example. More on the Typekit blog: http://bit.ly/a962Ke

  9. Van

    Van

    07 July 2011 @ 04:53PM #

    As an aside, I’m laughing hysterically at Pete’s ’elliotjayfontface’!

  10. Jonathan Hoefler

    Jonathan Hoefler

    07 July 2011 @ 05:03PM #

    As an aside (but maybe a useful one?) I think it’s 700 and not 600 that’s meant to correspond to a default “bold.” Signed, just euthanized one weight of a ten-weight webfont family.

  11. Mark Skinner

    Mark Skinner

    07 July 2011 @ 05:12PM #

    May be worth talking to John Daggett about this, I’m pretty sure his presentation at ampersand covered some of the proposed solutions and such (though I’m sure someone can clarify this)

    I know theres proposals for a font-matching service ( details http://www.w3.org/TR/css3-fonts/#font-matching-algorithm ) which could suffice and solve any issues. Though obviously fall-backs are mainly an issue on older browsers where this isn’t realistic

  12. Mark Skinner

    Mark Skinner

    07 July 2011 @ 05:16PM #

    Well I actually got confused, the font-matching algorithm is obviously just to put the font that is wanted on the page, there are other things in the working draft (can’t remember which) that will enable fallbacks for sizes etc to be defined :)

  13. André Luís

    André Luís

    07 July 2011 @ 05:18PM #

    One of the top items on my todo list is writing a script that will detect the font actually applied to an element.

    Eg:

    body { font-family: ‘FF Enzo’, Georgia, serif; }

    body[data-font=“FF Enzo”] {
    font-size: 1.2rem;
    letter-spacing: -0.06em;
    font-size-adjust: 0.64;
    font-weight: 600;
    }
    body[data-font=“Georgia”]{
    font-size: 1.1em;
    letter-spacing: -0.02em;
    font-size-adjust: 0.9;
    font-weight: 400;
    }

    etc.

    Sort of what modernizr is doing for features, but for fonts. Could this help the case of font-weights?

  14. Rob V

    Rob V

    07 July 2011 @ 05:55PM #

    I agree that it’s unacceptable and led me to be really frustrated when first introducing myself to webfonts. But as many people have already suggested, Google Web Font Loader is the solution as it allows you to declare fallbacks when a browser isn’t supported or the font itself fails to load.

    That said, I hate having to include another javascript library just for this, but expecting CSS to handle this for us might also be a stretch. Fallbacks are something we worry about consistently as web designers and developers and this seems like yet another consideration.

  15. Barry Schwartz

    Barry Schwartz

    12 July 2011 @ 08:39PM #

    I should let you know that you are serving web fonts in some way that fails with Firefox, perhaps due to cross-site restrictions. OTOH this has the benefit that your page came up in my browser in the much superior Fanwood Text (http://crudfactory.com/font/show/fanwood). :)

    I think the best solution to the problem might be to nuke all bold fonts off the face of the earth. :) But I do think the web currently is horribly inadequate in its font selection mechanism. I would want the full flexibility of something like TeX, to do whatever I want.

  16. thezenmonkey

    thezenmonkey

    12 July 2011 @ 08:49PM #

    As TypeKit and it’s Google web font implimentaion applies a class to the body, I just specify different weights depending on if the wf-active or wf-inactive class has been applied. I know it’s not the most efficient CSS, but it gets the job done. It’s a passible solution if you keep your HTML fairly light.

  17. Ryan Wake

    Ryan Wake

    12 July 2011 @ 09:14PM #

    This article leads me to something that I has been bothering me about webfonts. I, like a lot of designer/devs would love to use @fontface, however, the rendering is just too buggy IMO. Cufon is generally what I use on a consistent basis because it renders across all browsers most accurately.

    I have also noticed a huge difference between how a PC and Mac renders fonts. When you compare even a standard Helvetica or Arial font, there are totally different weights. Is there a solution out there for this? That has always bothered me. Just seems that it is one of those cases of just accept it and move on.

  18. Espen Brunborg

    Espen Brunborg

    14 July 2011 @ 10:54AM #

    It’s a very interesting problem you’re discussing here, one that to me seems to have come about – or should I say evolved – due to a fundamental lack of consistency between graphic design and web design. Historically (if one can say that about the last 20 years), web design as we know it emerged through the hard work of technical geniuses (read: nerds) who typically cared more about html than typefaces. There was never an appreciation for typography (until now, that is), which is probably why non-designer applications and systems tend to use an algorithm to slap on bold and italic to typefaces as opposed to using a different, specifically designed, version of the typeface. This leads to the confusion that Helvetica is a font, and you can “add” weights – or worse, styles – whereas in fact Helvetica is a typeface and Helvetica Bold is a font.

    Graphic design, on the other hand, evolved hand in hand with typography and the understanding of the distinction between a typeface and a font has been built into modern design software from version 1. In InDesign, to select Helvetica Condensed Bold one has to select the typeface (Helvetica) first, then choose the font (Condensed Bold) subsequently, as opposed to Microsoft Word where you either select the typeface from a list of all weights or, worse, select the typeface and artificially add Bold.

    So what’s the solution to this problem? I vote in favour of a system where both the typeface (ok, font-family) and font (font-weight) are defined as the designers intended, using text labels such as condensed, bold, ultra-light etc. Professional type foundries are already using this categorisation fairly consistently, and forcing them into a limited scale of numbers simply won’t work due to the range of fonts available for various typefaces.

    It does, however, add some work for the developer as “Ultra light” might not translate well to the next typeface in the font-stack, but I guess that’s just the price we should pay to utilise advanced typography on our sites. Besides, using SASS or other nifty tricks it’s easy to define these things in one place anyway.

  19. Richard Fink

    Richard Fink

    15 July 2011 @ 08:30PM #

    Hoefler’s right about 700 being the number corresponding to bold. Pls change. This is rather important. 600 is semi bold. At least that’s the norm in today’s batch of fonts on the market – commercial or free.

  20. Petra

    Petra

    29 July 2011 @ 02:04PM #

    I’ve had trouble grasping the whole concept of font weights. Your guide is really thorough and easy to follow. Thanks a bunch!

  21. FontMesa

    FontMesa

    30 July 2011 @ 04:04PM #

    In the 100 through 900 scale, do these numbers correspond to a measurement in the font design or is it for organization purposes?

    There are limitations with this scale, 100 thru 900 allows for only nine weights and how would you number the Book or Semi Light weight, 350?
    Another reason to number each weight would be to list a multi-weight font family in order from the thinnest at the top to the boldest at the bottom in your applications font menu list.

    In the scale above if you go further and produce 1000, 1100 & 1200 weights they will be shifted up numerically in the font menu and placed under the 100 weight.

    Most type designer’s wont produce more than nine weights in a font but some of us are crazy enough to see just how far we can push a font up in weight until you just can’t go any further.

    My next font release will be a multi-weight family, before starting the project I studied a few multi-weight type styles to measure how much of a change there is from one weight to the next.
    Using Helvetica for example, starting with the regular weight the change in vertical stem width starts out with a 24 point increase or decrease and the further away you get from the regular weight it changes to a 28 point difference, if there were semi or book weights then these would be only a 12 point difference.
    So with this in mind a fourteen weight font family is very possible and the best way to number each file would be 001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 012, 013, 014.
    If the book weight was considered to be 004 and you don’t happen to have a book weight in your font I would simple shift everything down making the regular weight 004, a missing number might confuse some customer’s.
    I don’t know how this would all work with Web fonts or whether web developer’s rely upon a 400 font being a specific weight.
    The numbering system simple appears to be a way of placing your multi-weight font family in order otherwise alphabetically bold will be listed before the light weight in your font menu and the regular will be last.
    Ciao, Michael

  22. FontMesa

    FontMesa

    31 July 2011 @ 07:22AM #

    In FontLab under the name and weight section there’s a list of weight choices to select for your font and the correct number beside it.
    The list is as follows according to FontLab:
    100 Thin
    200 Ultra Light
    200 Extra Light
    300 Light
    400 Book
    400 Regular
    400 Normal
    500 Medium
    600 Demi Bold
    600 Semi Bold
    700 Bold
    800 Extra Bold
    900 Heavy
    900 Black
    900 Ultra
    900 Ultra Black
    1000 Fat
    1000 Extra Black

    It is possible to type in your own weight name and number such as the unofficial weight of Hairline which would share a 100 with Thin but
    after font generation and import the custom weight name defaults back to one on the list.
    It was also possible to type in larger numbers in FontLab such as 1100, 1200, 1300 etc. and after importing the font back into FontLab the custom number value was still there.
    I would play it safe and not go over 1000 even if your font has fourteen weights or more.
    If the list in FontLab is the correct one to follow then fonts such as Helvetica Neue have the weights set incorrectly, in Helvetica Neue the Thin and Ultra Light weights are switched, Thin should be the lightest weight.
    FontMesa

  23. Petra

    Petra

    29 July 2011 @ 02:05PM #

    I’ve had trouble grasping the whole concept of font weights. Your guide is really thorough and easy to follow. Thanks a bunch!

  24. Jason Pamental

    Jason Pamental

    23 August 2011 @ 11:45PM #

    Hi Elliot -

    The article I wrote (with downloadable sample) is up now on the Fonts.com blog and I wanted to share it with your other readers. I just gave a talk about it today at DrupalCon London too and it seemed to go over well. Hope it’s helpful!

    http://bit.ly/pF5qlr

    Cheers-

    Jason

  25. Chris

    Chris

    18 October 2011 @ 02:23PM #

    If its ok to list fallbacks within one attribute, why not list them in others aswell?

    font-family: ‘ff enzo’, sans-serif;
    font-weight: 600, normal;

    I see no reason why this behaviour shouldn’t span the bulk of typography related attributes (line-height, letter-spacing etc).

© 2005 – 2014 Elliot Jay Stocks. All rights reserved. Powered by Harmony and tracked by Gaug.es. To keep updated with new content, you might like to subscribe to my RSS feed.