Font size inconsistencies with font-family: monospace
Just over two years ago I posted Sizing monospaced fonts. It is a short article accompanied by a test case that demonstrates the (to me) strange things that happen to font size in Safari when you use the monospace generic font family in CSS. In summary, specifying monospace as a font-family alternative will make Safari render text smaller than other browsers.
The article received very little response, so since then I have avoided specifying a generic font family as a backup for monospace fonts (Courier being the most widely used) in order to get similar font size across browsers. The other options would be to have monospace text be either unreadably small in Safari or oversized in other browsers.
I was a little surprised when I recently noticed that Apple’s Dave Hyatt had linked to my old article from his post Strange Medium at Surfin’ Safari. In the article Dave explains what is going on with monospace font sizing as well as why. And it sort of makes sense since the reason is to honor the user’s settings for monospace text.
What I’m wondering, and this is also mentioned in a comments on the article, is why the default setting (in most browsers, not just in Safari) is to make monospace fonts smaller.
It seems like we will have to continue avoiding the monospace generic font family if we want consistent and readable monospace text, but at least now it’s understandable why Safari behaves the way it does.
- Previous post: No more Transitional DOCTYPEs, please
- Next post: IE 7 is better but still lagging
Comments
It annoys the hell out of me! Firefox is decent, Opera is smaller, and IE is smaller again, then there is Safari...
I'll try the -monospace trick.
I've found a way to get monospace font sizing consistent in Safari is to explictly set the font size in pixels. For example, to get the basic text size down to 12px (as on this page), one can use these rules:
Essentially the first rule is there to reduce the font size for IE6 and below. Set as a percentage, it means IE/Win users can still resize their text.
The second rule sets the font-size in pixels for all other capable browsers - Safari, Firefox, IE7 all allow resizing of text set in pixels. And this also means that Safari's monospace font-sizing works as expected.
Rich: That sounds like an approach worth trying. Thanks for sharing :-).
I think Richard described why I never found such inconsistencies to be a real problem. I usually start with a px-defined font size for all browsers, and override it with a percentage-defined font size for IE6.
The font size base isn't always on body though, as I like to be able to detect/read IE's internal values on body, and that won't work if I overwrite them.
Maybe the best approach is to override any percentage action you've got going on elsewhere by going back to the keywords:
code { font-family: courier, monospace; font-size: medium }
Well, I think it's because that's how it's done in books.
If anything, you should be familiar with that. Am I right that monospaced fonts in technical books and guides are usually written as text input or code? It is almost always smaller than the body text, and frankly, I think it reads a little better that way.
Obviously the web is a different beast, but that's my theory anyhow.
Great timing on this article! I was just about to admit defeat (too large monospace font on all non-Safari browsers) when Google turned up this result.
I might try Rich's approach in the near future. Can't remember why I went with body {font-size:62.5%;...}, but I fear that setting the body font-size to 12px will upset my em-sized fonts, all of which are based on this 62.5%.
Sorry, comments are closed for this post.