CSS font-family monospace renders inconsistently in Firefox and Chrome
Posted on 25 September 2009
| problem | solution | overview all | bug reports | chrome/safari |
It is a well known, but little reported fact that the default monospace font for Firefox (and Chrome) is rendered too small, about 85% of the original size. But when you specify “monospace, monospace” (that’s right: twice!), the font will render as expected in the normal size. Weird? You bet!
Why monospace is too small
In the early days of Firefox, a lot of effort was put in to making the browser as Netscape compatible as possible. Users should have the same “feel” as when they used to use Netscape back in the old days. One of those “feels” of Netscape was a very tiny default monospace font, which was hardly legible. Older Internet Explorer had the same: the default was very small, about 60% of the 1em size of the surrounding font.
This bug, or feature if you like, has stuck around all the way until now. Though I haven’t tested this thoroughly yet with all existing versions of Firefox, my current version (3.0 and 3.5) contain this behavior still, while other browsers have meanwhile abandoned this odd behavior, with the exception of the newcomer Chrome (strange: Chrome is based on Safari, but recent Safari version do not show this behavior anymore).
Two old reports about the same: monospace is braindead and inconsitencies with monospace.
Inconsistencies with monospace in Firefox
It is one thing that you decide on a default size that is not consistent with the CSS standard, it happens all the time so let’s not spill blood over it. But it is another thing to change behaviors in situations that should be equal:
Example 1
<p style="font-family:monospace">1. This is monospace</p> <p style="font-family:unknown font, monospace;">2. This is monospace</p>
The two lines above should render exactly equal. But as you can see in the next section, it is not: these two lines show up in different sizes. Let’s take this one step further, what about the following piece of code, where we ask the renderer to choose between “monospace” and “monospace”?
Example 2
<p style="font-family:monospace">1. This is monospace</p> <p style="font-family:unknown font, monospace;">2. This is monospace</p> <p style="font-family:monospace, monospace">3. This is monospace</p>
For the record, I wanted to know whether this odd behavior also appears when you use a monospace font by hand. But the inconsistency is not consistent enough, because in this case, both lines render as expected and show up with the same lengths (and the same counts for any other font family, like serif, cursive etc):
Example 3
<p style="font-family:Courier New">4. This is monospace</p> <p style="font-family:Courier New, Courier New">5. This is monospace</p>
This is how they render, all five should be equal. The first one is the normal, most logical, with just “monospace”, which renders too small. The others are the variants that should render the same, but actually render according to the CSS specification. Hover over the paragraph to see what style was used.
More consistent inconsistencies with monospace in Chrome and Safari
There’s absolutely nothing that I believe can convince me why “monospace, monospace” would render differently then just “monospace”. Example 1 and 2 above should render consistently throughout for lines 1, 2 and 3. One could argue that if the default font is not Courier New that example 3 may render differently in browsers. But if you are browsing this page with Safari or Chrome you already know what I’m getting at. At least up to version 4.0 of Safari and up to version 3.0 of Chrome you’ll see the picture on the right.
What does it tell? Well, for all five lines it selects Courier New on my Windows system. But for some odd reason, when you specify “monotype” in any of the three first variants, it will render smaller then the surrounding font.
In other words: Chrome and Safari share the exact same bug with one difference: they have managed to implement the bug consistently! Is that better? No. In the next section, a little table shows how ridiculous situation is this “staying with Navigator 4 behavior” has brought us.
Overview
Basically, we have a serious cross-browser rendering issue here. I must admit, I am biased towards Firefox and to a lesser extend to Konqueror and Safari, but in this case I cannot draw any other conclusion then Internet Explorer and Opera being the kings of rendering “monospace” correctly.
For all browsers I used the same settings: the default for monospace was set to Courier New.
Bug reports
After some searches, it didn’t appear reported as such. There are some reports on the behavior of monospace and it incorrectly rendering to a smaller font than the ones around it. But the “monospace, monospace” bug is not one I have found so far, so I decided to report it myself.
Meanwhile, my bug report has been considered a duplicate. It was already reported: in 2002 (!!!).
Solution
Be careful when using monospace as the font-family. The default will be smaller then you expect. When you select it, i.e. as fallback on your main html or body element, you should consider specificying at least two items, where the first is an actual font, in which case the rendering will be as expected and according to the CSS standard.
An odd little bug that has come a long way from age-old Netscape and is a left-over from its features. Though I’d like to consider this a bug, and really not a feature.
– Abel –
Just to let you know: the blog is active again (you may have noticed that for a few months there were no updates). The reason was simple: it was hosted on a thin line and needed upgrading. It took a long while to find a reliable hosting provider, not too expensive, and with enough flexibility… read article
Visual Studio 2010 is yet to become full beta 2, but employees already saw the preview and the final release date is announced. In a few days, it’ll finally hit the market. Be ready to download this cool new version packed with new features. A little article on an estimated roadmap until the final release date — read article
Let’s try something new, let’s try Pinax! That’s one of the very few rather mature CMS’s around that have been developed completely in Python, with the Django framework as its basis. This article talks the non-Pythoneer through the installation process step by step. It only takes a few minutes! — read article
No responses yet. You could be the first!
Leave a Response
Additional comments powered by BackType

















