One of my favourite font stacks that serves optimised fonts for each OS has long included ‘Helvetica Neue’ [1]. It has better metrics than good old Helvetica (and pretty similar to Arial both in terms of aspect–ratio and line-height), it is more optimised for on–screen display, and, as a system font, it is guaranteed available. An additional advantage is that it is available in multiple font-weights for those browsers that support it (that’s currently Gecko and WebKit). Faces available include ‘UltraLight’, Light’, ‘Regular’ and ‘Bold’ — in CSS parlance these translate to font-weight: 100, font-weight: 300, font-weight: 400 and font-weight: 700.

With the release of OS X 10.6, Apple provides one additional face: ‘Medium’, with font-weight: 500. For a web developer (and more so for the end–user of a web page…), this results in a small surprise. When viewing a page that contains <strong> or <b> elements with a Gecko based browser, those elements suddenly look much less dark or fat than they used to on OS X 10.5. This is not unexpected, as the Gecko UA stylesheet (html.css) specifies b, strong {font-weight: bolder;}. The browser looks for a face that is one weight heavier than the previous one and finds the Medium face of Helvetica Neue. Although WebKit’s UA stylesheet contain the same rule, Safari and Chrome do not exhibit the same rendering behaviour.

That is a weird and puzzling bug in WebKit, as it can use the font when specified otherwise. Only font-weight: bolder is affected, and apparently only the Medium face Both ‘bolder’ and ‘lighter’ can result in the incorrect face being used, e.g when the computed value should be UltraLight, it is ignored. This seems specific to Helvetica Neue… This test case (or this test case, with screenshot) illustrates the issue. I suspect a little hack that was introduced in bug 6484 to cover up a bug in OS X 10.5 comes back to bite WebKit [2].

Turns out that I was partly wrong; the issue was already documented in bug 18323.

For a stylesheet author the workaround is rather easy, simply redefine the font-weight for the affected elements. Like this:

b, strong {
    font-weight: bold;

CSS3 Font Module proposal

The situation illustrates a deeper issue, however. In CSS 2.1:15.6 Font boldness: the ‘font-weight’ property, bolder/lighter means: select font weights that are relative to the weight inherited from the parent. This can lead to surprising, unwanted or confusing results when faced with (multiple) nested elements that make use of ‘bolder/lighter’, as summarised by this test case from David Baron. There have been a couple of extended discussions on this subject on the mailing list of the CSS WG (www-style). John Daggett, editor of the CSS3 Font Module came up with a proposal that suggests to replace the bolder / lighter definitions with a simple mapping that’s independent of the font family in use. This proposal has also been included in the editor draft of the CSS Fonts Module Level 3.

In short, with this proposal the issue noted above would simply not exist, the UA would map the font-weight of ‘bolder’ to font-weight: 700; – assuming that is that the computed font-weight of the parent is font-weight: 400;.


  1. David Baron has now effectively implemented the above proposal in Gecko 2.0b (browsers like Firefox 4). It has also made its way in the CSS3 Fonts Module draft specification, and will soon appear in an updated text of the CSS 2.1 spec as well — see CSS 2.1:15.6 specifically. [added Nov. 29, 2010].
  2. People using Windows builds of Firefox nightly builds who have DirectWrite enabled have mentioned seeing lots of ‘very bold’ text on the web. DirectWrite allows for using multiple weights of fonts on Windows; in this case, the ‘Arial’ font family seems affected, as the system appears to discover an extra bold weight (Arial Black, although not strictly part of the Arial font-family). Bug 550128 has some more details and a test case. Although OS X also ships with Arial Black, it is not affected in this case. [added Nov. 29, 2010].
  1. font-family: 'Helvetica Neue', 'Nimbus Sans L', Arial, sans-serif; one could argue about adding ‘Liberation Sans’ in there.
  2. The equivalent Gecko bug and workaround did not result in any issues.