Keep Your Font Stacks from Falling Over

For most web designers and developers, testing is a huge part of the job. They’ll devote a considerable amount of time ensuring that their sites appear similar, if not identical, in a wide range of browsers. One key part of site testing, however, seems to be all too frequently forgotten: font stack testing.

The Problem

Most web designers rely largely on a set of free, widely distributed fonts for much of their site’s text content. Yet, no matter how widely available a font is, there’s still a chance it will be absent from a given visitor’s system. Fortunately, CSS lets us specify a stack of fonts to use in case the preferred font is missing. By specifying three or four fonts in this manner, followed by a generic catch-all serif or sans-serif, we ensure that our content is displayed in a font that at least resembles the one we wanted. In theory that’s great, but if the appearance of the site isn’t tested with each of the potential fallback fonts, problems can arise. For example, when viewing the PharmQD website on my home machine (running Ubuntu Linux), I see the following:

As you can see, the titles break onto an extra line, which was clearly not anticipated by the designers when they were putting together the layout. Why? Because the font stack used for these titles is Tahoma, Verdana, Arial, Helvetica, sans-serif;, and Tahoma is significantly narrower (at the same font size and weight) than Verdana or Arial. So when viewed on a system without Tahoma, the fallback font is used, and since all the fallbacks are wider, the text takes up more space than was anticipated in the design. Here’s what the design was intended to look like, this time viewed on my work machine, running OS X:

Tahoma isn’t the only font vulnerable to this kind of breakdown. Microsoft’s Vista fonts (Calibri, Cambria, Candara, and Constantia) are significantly smaller than most others fonts at the same point size, so using any of these in a stack can result in similar issues.
Testing Tools

Strangely enough, despite the wealth of testing tools available for web developers, there’s no simple answer for testing font stacks. One less-than-ideal solution is to use Firebug to manually edit the font-family declarations associated with the parts of the page that are highly dependent on font size: buttons, navigation items, headings, and so on.

A quick Google search also revealed this promising-looking project on Github: Font Stack Tester, by Robert Lee-Cann. It’s a jQuery script that adds an overlay at the top of a page with buttons to disable any of the fonts found on the page. The developer wants to eventually turn it into a bookmarklet, but at the moment it’s definitely in its infancy.

Update: In the few days since I originally posted this, an enterprising individual has registered http://fontstacktester.com/ and put up a hosted version of that GitHub project. Just enter your site URL, and it will take you there, adding a bar along the top that you can use to disable fonts one by one to test how your stacks hold up. Kudos to Chris for the speed with which this was developed!

No matter how you go about it, font stack testing should definitely not be neglected: when something breaks as badly as the example above, it can really damage that visitor’s impression of your site.

Louis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.

http://randsco.com stk

While testing a font stack is always a good idea, the advent of cross-browser font embedding (using the CSS3 @font-face selector) obviates the need for more than 2 fonts in a stack.

Designers can pick the font they want and use it. If a visitor doesn’t have the font installed locally, they’ll download it with the page. If a visitor does have the font installed locally, the system font can be used – saving the weight of the download.

Hope this helps!

http://blog.thenetgen.com agentforte

If you don’t have too many style sheets and/or fonts, it can be fairly easy to do a global replace of fonts, removing one font at a time to test the entire stack.

Of course it is always good to add this to your check list so you remember to budget time to test these things. It would be cool to have some JavaScript to easily swap through the stack to compare fonts and layout.

http://www.tyssendesign.com.au Tyssen

The problem with the site you’ve shown is only partly because they’ve neglected to test their font-stack correctly. Their main problem is using fixed heights for everything. This problem would’ve shown up if they’d bothered to test the site at different text sizes which is much easier to do than playing around with font stacks. If you design your layouts to take into account people viewing your site at text sizes different from the default you intended, you can avoid a lot of the problems that will occur if a font isn’t present.

Louis Simoneau

@stk: Yep, true. Of course, even a stack of two can fall over! And using @font-face might make that less likely, but network errors or service provider outages could still lead to the font file being unavailable.

Louis Simoneau

@Tyssen: When I started doing web design, that was definitely true: since browsers “zoomed” a page by resizing its fonts, you needed to account for differing font sizes in your layout. But nowadays almost all browsers zoom by magnifying the whole page, so font-resizing is less and less of an issue.

mwistrand

@stk That is assuming, of course, that the font is either free or you have permission from the foundry to distribute the font via the @font-face property. However, since most fonts used on websites do not fall under this category, this solution is unfortunately very limited.

memco

@Louis: Unless you’re like me, and you turn off full page zooming because you don’t want to have to scroll horizontally just to read text.

Anonymous

@Louis Simoneau

When I started doing web design, that was definitely true: since browsers “zoomed” a page by resizing its fonts, you needed to account for differing font sizes in your layout. But nowadays almost all browsers zoom by magnifying the whole page, so font-resizing is less and less of an issue.

Even though a lot of people use the zoom functions of browsers, some people do still adjust the text size instead (including everyone using IE6, but equally some people using browsers that do have a zoom feature), so you should still make sure the site works with text resized.

CC

I don’t quite understand how to use this jQuery without hard-coding it into each page I want to check. Is creating a bookmarklet out of this code that difficult to do? I have no experience with it but I’d be willing to learn because this seems incredibly useful to me.

arts-multimedia

Their main problem is using fixed heights for everything. This problem would’ve shown up if they’d bothered to test the site at different text sizes which is much easier to do than playing around with font stacks. If you design your layouts to take into account people viewing your site at text sizes different from the default you intended, you can avoid a lot of the problems that will occur if a font isn’t present.

I agree with this. Linux creates an additional problem. Sizes of standard fonts on Linux are often bigger then on PC and Mac. (Linux or font makers for Linux should solve this actually). Apart from that, I always use at least 3 to 4 backup fonts.

Designers can pick the font they want and use it. If a visitor doesn’t have the font installed locally, they’ll download it with the page.

@stk, are you aware you have to buy a special license for that? Adobe asks over $500 to allow for distribution per font.

http://randsco.com stk

@Louis – Yes, which is why I agreed that testing is always a good idea. I was more letting your readers know that the need for stacks involving: “your ideal font, which likely isn’t loaded”, “close match”, “next-close match”, “something common & sorta close”, “generic font” … are no longer necessary.

The next article on randsco will cover relative sizing of fonts in a font stack – what tools exist today to combat fonts that are vastly different size, at identical em sizes.

seutje

not to be a dick or anything, but the problem you outlined is a clearing issue due to the numerous (useless) height definitions on that page

if that h2 simply contained more text, but in the correct font, it would still break

I’m not saying that testing isn’t a good thing, or that people shouldn’t be using fall-back fonts, just saying that respecting the natural flow of html documents pretty much eliminates the problem altogether

Totally. I’ve seen a number of older GPs that need to wear fancy eyewear in consultations so that they can see what it is that is wrong with me – so it’s likely that they’d also need to increase the font size on that web page for more comfortable viewing.

However, looking more closely, the stock photo in the MyPharm box is the real giveaway. It’s not just the web developer that didn’t care on this job, seems like the client was pretty ambivalent about the whole thing too.

But nowadays almost all browsers zoom by magnifying the whole page, so font-resizing is less and less of an issue.

I think that’s a dangerous assumption to make. All browsers that offer page zoom still offer the ability to only resize the text, in fact that’s the way I’ve got my browsers set up as I don’t like page zoom.

For the non-tech-savvy user who learnt how to use the Internet using IE6, I think that assumption’s even more dangerous to make. If someone learnt how to resize text in IE6 using the five text size options, there’s a good chance they’ll continue to use that method with newer versions too (which includes IE8).

My point is, that regardless of how the end user resizes text, it’s easier for a developer to get an idea of how a layout might appear if a larger font is substituted by setting your browser to resize text only and then using your scrollwheel to move it up and down than to fiddle around in Firebug adding and removing fonts.

http://www.tyssendesign.com.au Tyssen

And I should add, that coming back to my original point, fixed height elements are still bad because you can’t be certain that a user doesn’t have their default text-size set higher than you intended which again is something you need to test by resizing text only, and not zooming the page.

http://louissimoneau.com Louis Simoneau

Really good points by Tyssen et al about fixed-height elements in general. CC asked about turning this into a bookmarklet…I don’t imagine that would be terribly difficult, but someone already picked up from this post and developed a web-based service to test your font stacks: http://fontstacktester.com . It’s also a little rough around the edges but is much easier to put to use without altering your code.

David Hucklesby

@Louis – You said “But nowadays almost all browsers zoom by magnifying the whole page, so font-resizing is less and less of an issue.”
To add to memco’s reply to this, I’d note that settings other than “larger text” affect the size of displayed text. Not only browser settings such as minimum font size, but also Windows and other OS DPI settings.

Anonymous

I have a wonderful utility by Sue Fisher from 1999(!) called Font Thing, originally designed to run on Windows 95, Windows 98 and Windows NT 4.0. You can still find it at her original home page: http://members.ozemail.com.au/~scef/index.html

Among the features she doesn’t mention, is that you can select any number of fonts to display and compare “side by side” for font stack purposes.

It appears the site has been inactive since Jan. 2000, but all the Font Thing info is still there, and I have happily upgraded my hardware and OS over the years to now be running it on an HP compaq notebook, WinXP SP3 system with no apparent glitches, but then, I’ve never used it to it’s full potential, so who knows?

What I do know, is that when I’m looking for a font to emulate one a client specifies that I don’t have, need to compare “like fonts”, or need to check various fonts for stack suitability, Font Thing is invaluable!