We all love a bit of Helvetica, especially on websites. For the last few years having a CSS font stack that specifies Helvetica Neue followed by Arial has been the most popular way to do it, with the aim of presenting Mac users with Helvetica Neue (which is installed on every Mac) whilst Windows users see Arial (a Helvetica variant optimised for Windows). I don’t know who invented the technique, but you see it recommended everywhere and I’ve used it loads myself. But recently I’ve stress tested this font stack a bit more (hey there BBC GEL) and found a few problems with that have caused me to change up my approach.

The first issue affects pre-Snow Leopard Macs with Adobe’s extended font pack installed. On these machines Safari renders Helvetica Neue Bold as Helvetica Neue Bold Outline. Cool display font, but its almost invisible when set in for text onscreen. If you’re just looking at raw numbers this issue is quite rare, but unfortunately there’s a pretty notable demographic where this setup comes as default on every desk - large design agencies. The same agencies that commission websites by the hundred and really care if things look broken.

Another bug hits Windows users with a pirated version of Helvetica Neue installed on their system. This in combination with various CSS styles triggers Webkit into having a bit of a breakdown.

These are the bugs I’ve consistently reproduced, I get reports of others but I haven’t managed to replicate them myself. Either way, both bugs occur in modern browsers & render the page unreadable, which is enough reason to look into a different solution. As I was mid Wikipedia-ing some background information for the problem, I noticed that Wikipedia itself renders in Helvetica (on a Mac) yet doesn’t have the bug. Turns out that Wikipedia simply specify the following:

font-family: sans-serif;

A bit of testing revealed that for the most part, just specifying sans-serif will give Windows users Arial and Mac users Helvetica. The only edgecases are Opera for Mac (which interprets sans-serif as Lucida Grande) and Linux browsers (which seem to pick an arbitrary font from a hat, but then as they don’t have Helvetica Neue or Arial installed this was how they were behaving previously anyway).

We can reign in Linux by specifying a couple of open-source Helvetica derivatives that are installed on all the main Linux distros; Helmet & Freesans. I’ve been in contact with the Opera for Mac team about it, and they’ve said they’ll change their sans-serif output to Helvetica or Arial within the next couple of releases to benefit platform consistency.

So here’s the font stack:

font-family: Helmet, Freesans, sans-serif;

And here’s a table of what you can expect to see as a result:

Update

Since I first wrote this I’ve had the chance to test the font stack on a decent selection of mobile devices, so I’ve updated the table to show those findings. Due to the limited selection of fonts available on many mobile platforms (and my unfamiliarity with many of them) I’ve added more options to the test page.

Windows
IE	Arial
Firefox	Arial
Webkit	Arial
Opera	Arial
Mac
Firefox	Helvetica
Webkit	Helvetica
Opera	Helvetica
Linux
Firefox	Helmet or Freesans (open source alternatives to Helvetica)
Webkit	Helmet or Freesans
Opera	Helmet or Freesans
Other
Android 1.6	Tahoma (is displayed for all sans-serif font stacks)
Android 2.2	Tahoma (is displayed for all sans-serif font stacks)
Android 3.0.1	Droid Sans (is displayed for all sans-serif font stacks)
Blackberry OS 5	BBAlpha Sans (is displayed for all sans-serif font stacks)
Blackberry OS 6	BBAlpha Sans (is displayed for all sans-serif font stacks)
Blackberry Playbook	Arial
iPhone	Helvetica
iPad	Helvetica
Kindle 2	PMN Caecilia (is displayed for all sans-serif font stacks)
Kindle 3	Helvetica Neue
Nook	Tahoma (is displayed for all sans-serif font stacks)
Windows Mobile 6.1	Tahoma (is displayed for all sans-serif font stacks)
Windows Mobile 7	Tahoma

You can pretend it's 2005 and subscribe to my RSS feed