Using Type: Getting @font-face Right, Preventing Faux Bold

First, thanks Art Blanc for requesting that I add this brief bit as an extension to Using Styles Properly. Designing with professional webfonts, you’ve generally got two options. Host your own, or go with someone like Typekit or Webtype that handles the hosting and serving of font files as needed. I’ll focus on the first case, but this is still pretty applicable to the second, as it will point out why problems like faux bold and faux italic occur, and how to fix them.

Using Type, set in FF Legato

If you use a single font family of four fonts, don’t specify four separate font-families. This is the most common mishandling of the @font-face rule I see, and the main reason for faux bold’s inescapable presence on the web. Instead, specify the same font-family with each font, and use font-weight and font-style to differentiate them, like this simplified example with FF Unit Web Pro:

All the same font-family

What if I want to use weights within the family that are neither ‘normal’ nor ‘bold,’ like, say, Thin? Use numbers. 100 is the lightest. 900 is the boldest. Units increment by 100. Specifying a font-weight value of ‘normal’ is the same as 400. Bold is 700. Here’s the spec.

And actually, let’s take a detour here and discuss faux bold. When setting up @font-face, the default value for font-weight is normal, or 400. When using a header in your markup, h1, h2, or whatever, the header’s default font-weight is bold, or 700. So if you specify a separate font-family for headers without specifying its font-weight, and then turn around and use it like I use FF Meta Headline Web Pro below, you’re headed for trouble.  Why? Even though the font is called MetaHeadlineWebPro-Bold, since the font-weight isn’t specified, CSS thinks it’s ‘normal.’ Then when the h1 comes asking if there are any ‘bold’ fonts in the family, CSS says, “No, but I’ve got this normal one here I could bold up for you real quick.” Faux bolding is applied.

What could go wrong?

Meta Headline Web Pro Bold, faux bolded

The common quick fix is to specify font-weight: normal; in the h1, avoiding the above described confusion. And sometimes with webfont services, this is what you have to do. But the better way of handling it, is to specify font-weight: bold; in the @font-face CSS. Next time when the h1 comes looking for bold, CSS says, “We have it.”

Now, why’s this better? Because you don’t always know who’s going to come looking for bold, or italic. You might fool h1 into looking for ‘normal,’ but what about h6, or h7, or strong, or b? If you set up your @font-face right, you don’t have to go preempting each of these eventualities. Elements like em or strong find the font they’re looking for, without you having to tell them where to look.

In sum, apply style rules as generally as possible, or if you can, implicitly. That’s all for now. Another Using Type comes on Thursday. In parting, here’s the beautiful Aften Screen, with its totally already-thought-out CSS bundled with the download.

Sparely written CSS

Aften Screen Web

(Update: Hey Alan Stearns! I just read your Say No to Faux Bold and discovered that I must be an unwitting plagiarist. Though I didn’t reference your material at the time of writing this post, it seems like somewhere in the middle there, had I done so, and copied you idea for idea, the words wouldn’t have come out too different. I could claim that I arrived at this independently – actually I will claim that – but still, what’s the use? The two are so close. Anyway, sorry for what must certainly have looked like me ripping you off.)

Readers: though Alan and I come to the same conclusions, he goes into more depth afterward.

4 Comments

  1. jamesckemp
    Posted February 15, 2013 at 10:54 AM | Permalink

    I see this all the time as well. I find it odd that services like fonts.com don’t even handle it properly!

  2. datenkind
    Posted February 17, 2013 at 11:58 PM | Permalink

    There is no h7 in HTML, please fix this.

  3. Posted February 18, 2013 at 2:26 PM | Permalink

    I’m glad to see more posts pointing out the right thing to do. If you look at the comments on my article, you’ll find that we both unwittingly plagarized @spaceninja.

  4. Posted February 20, 2013 at 8:30 PM | Permalink

    @datenkind:You’re right, but h7’s lack of existence doesn’t always prevent its use, nor does it prevent browsers from supporting it. The point I try to make by including it in the piece is that we designers don’t always know which elements will trigger what styling, so it’s best to specify implicitly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 61,743 other followers