The @font-face future is STILL not yet now

Ever month or two, I revisit the state of @font-face on the web to make sure I don’t need to update or overhaul last summer’s screed about web fonts. Believe me, I am anxiously awaiting the day when everything I said in that post is no longer true or — better yet — irrelevant.

Today is still not that day, despite my having found — how did I miss it? — A List Apart’s article on the topic that predates my own. The last few paragraphs really underscore why we are still only at the “crossing” with fonts:

…I’m uncomfortable with the idea of having an outside entity in control of something as basic and fundamental to the design of my site as a typeface. Further, every independent web designer I’ve spoken to about it has said they simply would not, under any circumstances, saddle a client with an ongoing expense for fonts.

And, regarding actual implementation:

All together now, let’s get really confused…

The waiting continues.

The @font-face future is STILL not yet now

Honing a Cross-Browser Font Stack

It is a testament to many things that I didn’t find this problem sooner, but apparently it is more difficult to arrive at an effective cross-browser font stack than I previously thought.

I have the good fortune to be working on a website redesign with a client and a designer who are realistic about web fonts.  They agreed that while Trade Gothic Condensed No. 18 was ideal for the headlines on the site, Arial Narrow would suffice when users didn’t have Trade Gothic installed.  Thus began my epic quest for a font stack that would work in all browsers.

The Problem

At the outset, I couldn’t figure out why font-family: "Trade Gothic Condensed No.18", "Arial Narrow", Arial, sans-serif; was not doing the trick. It wasn’t just not showing up on one or two browsers, it wasn’t showing up on any of them!

So I did a search for “font-family: trade gothic”. After a few modifications to my search, I found a number of situations where developers had “TradeGothic” in their font stack. Having never seen this space-less construction, I dug deeper.

Eventually, my search turned up a very thorough blog post by Rachael Moore fittingly titled Declare a Safe Font Stack With CSS Font-Family?, the upshot of which was that different browsers use different standards for naming fonts and font families.

Some interpret spaces in the name as spaces, some as dashes, and some prefer no spaces at all.  (I am not too proud to admit that this led me to hours of creating the most enormous font stack ever conceived, where I listed every possible permutation of “Trade Gothic Condensed No.18” with spaces, without spaces, with dashes, without dashes, with some words abbreviated and some not, etc).

Furthermore, some browsers (for instance Chrome) will accept styling inside the family name, e.g. “Arial Narrow Bold”; whereas other browsers (Firefox, for instance) take only family names, e.g. “Trade Gothic”, and relegate styling such as bold or italic (or “Condensed No.18”) to CSS properties like font-style and font-weight.

This last revelation led almost instantly to despair for me.  How was I going to be able to achieve bold for one browser but not the other without some very disappointing hacks? What could I possibly do about “condensed”?

The Solution

Luckily in my case I wasn’t trying to bold something.  Going forward, I’ll probably just always do that with font-weight rather than in the font name.  (Let’s not start thinking about what’s going to happen when I want a non-bolded font to cascade down to a bolded one).

But condensed was pretty key to my current mission.   This is where Moore’s post came in handy once again, as it introduced me to the concept of “font-stretch”.

Never heard of it? Neither had I.  Do a Google search for it. Click that w3schools link and then ctrl-F “font-stretch”.  Weird, right? Read on and you’ll discover what I did, which is that apparently this property is a spottily implemented one at best, and at the very least controversial. Luckily for us, Firefox, the main perp as regards strict font-family names, has started supporting font-stretch.  Also, and this is key, the other browsers seem to ignore it.

So, drumroll please, here is my working cross-browser font stack for “Trade Gothic Condensed No.18”:

font-stretch: condensed; font-family: "TradeGothic-CondEighteen", "Trade Gothic Cond Eighteen", "Trade Gothic Condensed Eighteen", "Trade Gothic", "TradeGothic", "Trade-Gothic", "ArialNarrow", "Arial-Narrow", "Arial Narrow", Arial, sans-serif;

Honing a Cross-Browser Font Stack

Why the future is not yet now: The truth about @font-face

I’ve had a number of clients come to me recently claiming that — because of growing browser support for the CSS rule @font-face — the future is now and they should be able to have whatever fonts they want for body copy (and everything else).  They’ve seen the Google Font API or Typekit and they’re certain that the floodgates have finally opened.  What ensues is a painful conversation about intellectual property, font foundries, and free fonts.

Unfortunately, the future is not now.  You cannot use Helvetica or Trade Gothic for your body copy unless said body copy is part of a Flash movie (or worse an image!).  It is still illegal to make rights-protected fonts downloadable on your website — which is what @font-face does.  Yes, you can now easily embed web-licensed fonts on your website.  And yes there are many services making this easy and fast to do.  But I have yet to meet a professional graphic designer who is willing to confine themselves to those fonts.

Why the future is not yet now: The truth about @font-face