¶ The CSS 1 font-weight property is used to display text with a Bold or Regular weight. This is achieved using font-weight:bold and font-weight:normal. So much so CSS 101. But there’s more to the lives of many typefaces than just bold and regular. There’s Ultralight, Extralight, Light, Thin, Medium, Book, Semibold, Demibold, Extra-bold, Heavy, Black, Extra-black, Ultra-black, and more besides.
Since its inception in 1996, CSS has provided a way of displaying these other weights through use a numerical scale with the font-weight property. This is still almost entirely broken in every current browser except Firefox 3 on Mac.
How it should work
As well as the normal and bold keywords, font-weight also takes nine numerical values of 100, 200, through to 900. These numbers span the scale from Ultra-light to Ultra-black, with normal defined as 400 and bold defined as 700. So to specify a Light weight you would write font-weight:200. Here’s a rough guide matching the numeric scale to common weight terms:
| 100 | Thin, Hairline, Ultra-light, Extra-light |
|---|---|
| 200 | Light |
| 300 | Book |
| 400 | Regular, Normal, Plain, Roman, Standard |
| 500 | Medium |
| 600 | Semi-bold, Demi-bold |
| 700 | Bold |
| 800 | Heavy, Black, Extra-bold |
| 900 | Ultra-black, Extra-black, Ultra-bold, Heavy-black, Fat, Poster |
The numerical scale only loosely matches weight names as there’s no official definition of the terms – it’s entirely down to the typeface publisher whether a font be called Heavy or Black, or whether the font should be Extra-light as opposed to Ultra-light, so you may have to play around a bit.
What actually happens
I created a test case using Myriad Pro, as it has plenty of weights to play with; in my case I have Light, Regular, Semibold, Bold and Black installed. If you don’t have Myriad Pro installed, you’ll just see a monospaced font, but feel free to download and edit the text case file, and play around with another typeface. Incidentally I used the exact same PostScript-flavoured OpenType files for both Mac and Windows testing. The markup I used in the test case is roughly this:
p { font-family:"Myriad Pro" }
#one { font-weight:100 }
#two { font-weight:200 } ...
#nine {font-weight:900 }
<p id="one">100 why pangolins dream of quiche</p>
<p id="two">200 why pangolins dream of quiche</p> ...
<p id="nine">900 why pangolins dream of quiche</p>Firefox 3 on Mac renders the test case as follows:
Firefox 3/Mac: renders correctly
As you can see 100, 200 & 300 are rendered using the Light weight, 400 & 500 use the Regular weight, 600 is rendered in Semibold, 700 in Bold, and 800 & 900 are rendered using Black. This is the correct behaviour.
However Safari 3.2, Opera 10.00 Alpha, Firefox 3.0 on Windows, and Internet Explorer 8 Beta 2 all get this wrong in the similar, but subtly different ways.
Safari 3.2: 100–500 rendered in Regular, 600–900 in Semibold
Opera 10 Alpha: 100–500 rendered in Regular, 600–900 in Bold
Firefox 3/Win: 100–500 rendered in Regular, 600–900 in Semibold
IE8 Beta 2: 100–500 rendered in Regular, 600 in Bold, 700–900 in Semibold
For the most part these browsers partially support the numerical scale, but only for two weights; Regular and either Bold or Semibold.
A workaround
There is a workaround. Following on the heels of Guillermo Esteves, it involves the clever addition of some font-families. As well as the font’s family name – Myriad Pro in the test case – each installed font weight has two other names: the screen name, eg. Myriad Pro Light and the PostScript name, eg. MyriadPro-Light (to find these names, use a font management tool such as FontExplorer X and click info for the font). To get Opera, IE8, Firefox 2 and Firefox 3/Win to render an alternative weight, you need to specify the screen name, so the test case would need to be modified as follows:
#one {
font-weight:100;
font-family:"Myriad Pro Light", "Myriad Pro"; }However this doesn’t work in Safari, which needs the PostScript name. So your styles need to be further modified, as in the modified test case:
#one {
font-weight:100;
font-family:"MyriadPro-Light", "Myriad Pro Light",
"Myriad Pro"; }There are distinct downsides to this workaround. Obviously the first is that you need to specify at least three font families just to change the weight. But the main problem is that font-weight will no longer work (apart from in Firefox 3/Mac) as the font-family you are now specifying only contains the one weight. So if you need an Bold word within a Light weight paragraph, you’ll have to specify the font-family as well as the font-weight. Not very practical.
Frankly it’s really depressing that this bug is still present after 12 years, and regardless of success or otherwise in Acid tests, these browsers cannot truly say they support even CSS 1 fully or correctly. I hope we see fixes soon (apparantly already done in WebKit). I know fonts are a tricky subject in operating systems, but if it can be done in Firefox 3/Mac then surely other browsers can quickly follow.
Comments
1
Very interesting finding, I tried one time to use the Light, Thin, Medium typefaces and saw no effect, didn’t go in such details as you did though :)
Really weird thing that IE8 does, all the other browsers seem to follow a pattern, even if they don’t render correctly.
2
The latest Webkit nightly doesn’t render it correctly, but it got more in-between steps than Safari:
http://flickr.com/photos/yatil/3194249000/
3
Firefox 3 on Linux works as well – DejaVu Sans has multiple weights, and the test case is correctly rendered using that font.
http://www.kryogenix.org/random/ff3-linux-fontweight.png
4
Thanks Eric. I suspect Webkit is getting it right, and that maybe you don’t have a Light weight installed (feel free to correct me). That said, the word in the final sentence should be in Bold, so something’s not quite behaving correctly.
Thanks too Stuart: It’s good to know Firefox 3 on Linux is getting it right.
5
My Firefox 3.0.5 under Mac OS don’t know anything about bold nuances:
http://www.picamatic.com/show/2009/01/13/04/55/1736950_793×721.png
Maybe you talking about FF 3.1?
6
pepelsbey – I’m testing with Firefox 3.0.5, and it looks to me like yours is working just fine too. From what I can see, you only have Regular, Semibold and Regular weights installed, and screenshot indicates that Firefox is indeed rendering three different weights. According to the spec, browers shouldn’t try to simulate the missing weights but use the nearest installed weight, which is what Firefox is doing.
7
I got even stranger results on Firefox 3.1b2 on a Mac, it was having problems with the ” before and after the font name, as is it would not render the type, remove one (via web developer toolbar edit CSS option) and it worked almost, see below. I would blame it on being beta or the fact I am reorganising my fonts (I have same versions as you installed and active).
However, the webkit nightly build achieved slightly better results.
http://www.flickr.com/photos/nickobec/3194820799
8
The problem isn’t so much the browsers themselves, but more the underlying OS font APIs. MacOS X makes this relatively painless, but it’s fairly painful on Windows – in most cases, you have to combine “Myriad Pro Condensed” “Myriad Pro Regular” “Myriad Pro Semibold” etc. all under “Myriad Pro” with the right weights. OS X/ATSUI are able to do this fairly easily; the other APIs aren’t, and the app has to do a lot more work.
There’s an experimental patch for Firefox that we weren’t able to get in for 3.1 that had some variant of this working; hopefully we’ll be able to revisit that for the version after 3.1.
9
Nick – Thanks for the input. Good to see WebKit’s getting in right. Not sure what’s happening in Firefox 3.1b though.
Vlad – thanks for the explanation. I thought it must be something to do with the APIs, and I had noticed some strange things going on in Windows where the font family names were identified differently to those on a Mac, even though the exact same font files were used. As you say, it seems the browser has to do more work interpreting fonts on Windows than on a Mac.
10
Rich, cleared my font cache and found the Firefox 3.0.5, Firefox 3.1b2 and a recent WebKit nightly on Mac OS X 10.5.6 render the first nine paragraphs exactly same as your example.
The only difference is the last paragraph, Firefox and WebKit treat strong and b “tags” differently. Firefox increases the font-weight by one step Light becomes Regular, Regular becomes SemiBold etc. Webkit increase the weight by 100. So 100 becomes 200 and remains light in this example.It is only with font weights of 300, 500, 600, 700 that strong and b “tags” have effect.
11
Rich, was your screenshot taken on 10.4.x ? Seeing Nick Cowies’s result, I have the nagging feeling that it is a known issue on 10.5.x (in short it is an Apple Bug, see this Bugzilla bug for Helvetica Neue). WebKit worked around that.
I can’t test this unfortunately, as I don’t have the Light Myriad Pro. And of course, I could be wrong… (all versions of Firefox I have 3.06pre, 3.1b3pre and 3.2a1pre display the test case correctly otherwise.
BTW, did you notice that WebKit doesn’t display the word ‘bold’ in a bolder face ?
12
Oddly enough, I get one more step on Opera 10.00/1229 on Windows. I don’t have Myriad Pro, so Opera reverts to Arial, but I’m seeing the same behavior on multiple fonts: 100–500 render normal and 700–900 bold, while 600 is a distinctly semibold weight. Changing to other fonts and increasing the size make it clear that the 600 weight is a fake semibold produced by the browser. I also tried Adobe Caslon Pro, which has an actual semibold variant, but I get the same fake 600 with normal and bold surrounding it.
13
Correction: I didn’t get Adobe Caslon Pro to render, so I’m not sure how it would handle an actual semibold variant. In fact, I discovered several fonts are listed in Photoshop that don’t show up in Opera (including Myriad Pro – I do have it), so I’m guessing there’s an issue with supported file formats.
14
If you selected a different font you would see that Firefox 3 has the worst font handling ever. Just try to use a real “100/Ultra-light/Extra-light”-weight font, for example Neue Helvetica Ultra-Light. As you will see it will be rendered as Neue Helvetiva Light.
And since Firefox 3 does not accept full font names as font-family CSS values there is no way to get Firefox to render anything that is lighter than light.
15
http://flickr.com/photos/nickobec/3197214591/
Firefox 3, Firefox3.1b2 and WebKit nightly on Mac 10.5.6 giving almost identical results. After clearing font cache (was reorganising my fonts hence problems with earlier screenshot).
16
at – that bug in Firefox is specific to the version of Helvetica Neue shipped with Leopard, as reported here, and is caused by a bug in OS X 10.5. For other typefaces with an Ultra-light weight (including Helvetica Neue LT Std), Firefox renders the Ultra-light properly.
Quite how you can describe Firefox 3 as having ‘worst font handling ever’ is beyond me. I think this post makes it clear that Firefox 3 has, in fact, the best font handling ever.
17
Firefox 2 renders Neue Helvetica Ultra-Light as Ultra-Light on the same system and with the same HTML/CSS files while Firefox 3 does not. In fact, a step backwards.
18
Only true when using the font-family hack. Firefox 2 doesn’t support the proper way to do it.
In terms of overall type support, you should also take into account the quality of the text rendering on Firefox 3, which is hugely superior to that in Firefox 2. And I’m not just talking about the inclusion of ligatures and support for PostScript fonts, both of which Firefox 2 lacks, I’m talking about the quality of the Cairo graphics engine, compared to QuickDraw.
It is unfortunate that Firefox 3 can’t yet render the Ultra-light weight of the Helvetica Neue which ships with Leopard – I bemoan that as much as the next person – however the underlying cause is a bug in OS X 10.5, and it’s particular to one weight of one particular version of a typeface, so it shouldn’t be allowed to overshadow the otherwise superior support in Firefox 3
19
I know this isn’t an answer, but any chance of a javascript workaround with this (to the extent that is able in the browser?) – like some way to check the fonts on the system (if for instance, “Myriad” is chosen, then check for the weights, and assign the weight a number, and if that number is called, do a css font-family call, as you described above.
Don’t know it’s possible, just thought about it as I read. As I said, it’s not ideal, but it’s a workaround and possibly a way to make it work for those who have js enabled, those who don’t would get normal browser, so no harm no foul there.. not sure if it’s possible though…
20
Thanks for your great post!
I change fonts on poorly designed websites a lot with Stylish
and now I can use Optima Medium, my favourite!
I’m glad that my browser now handles OpenType Fonts correctly,
I wish support of “Condensed/Extended” Fonts would be added as well.
Add your comment
Comments are now closed on this post. If you have more to say please contact me directly.