Normalize.css: Please explain monospace, monospace one more time :)

Created on 16 Feb 2016  Â·  6Comments  Â·  Source: necolas/normalize.css

Duplicate of #513, but I still don't get this and I'm curious.

I read the source link, but the explanation at the bottom does not seem to recommend monospace, monospace. They went for monospace, sans-serif (not that I understand that any better).

What exactly does the duplication solve? Which browsers does this affect, and why does duplicating the font name fix it?

Most helpful comment

Major web browsers reduce the text size of elements whose font-family property is explicitly set to monospace to account for the greater width of many monospace typefaces in comparison to other fonts at the same text height (citation).

Browsers using Blink, Gecko, and WebKit reduce the size of monospace. Therefore, the monospace,monospace fix applies to Android ≤ 6, Chrome ≤ 49, Firefox ≤ 45, iOS ≤ 9, Opera 15-35, and Safari 5-9. The fix does not work for Safari ≤ 4.

Browsers using Presto and Trident treat monospace normally. Therefore, the monospace,monospace fix is not required for Edge 12-13, Internet Explorer 8-11, Opera ≤ 12.15, and Windows Phone ≤ 8.1.

Since they are checking explicitly for a computed value of monospace, other fixes may be applied, such as monospace,serif or _,monospace, if we feel one of those or something similar would be more readable.

All 6 comments

ok I just found some more issue dupes and it's a bit clearer now.

but I still have one question: if I'm using my own custom font stack that falls back to monospace, do I still need two of them?

i.e.

font-family: MyCustomMonoFont, monospace, monospace;

// or does this do the job:
font-family: MyCustomMonoFont, monospace;

I can't remember how many times the monospace, monospace was the main topic of an issue; but if this still generates confusion there must be a reason —besides that the hack looks super weird.

The reality is that there's not enough information about which browsers/versions are affected by this bug... and the explanation we link dates from "December 2009".

I'll do some testing about this, and try to come up with more specific details.


AFIK you're OK with:

font-family: MyCustomMonoFont, monospace;

Major web browsers reduce the text size of elements whose font-family property is explicitly set to monospace to account for the greater width of many monospace typefaces in comparison to other fonts at the same text height (citation).

Browsers using Blink, Gecko, and WebKit reduce the size of monospace. Therefore, the monospace,monospace fix applies to Android ≤ 6, Chrome ≤ 49, Firefox ≤ 45, iOS ≤ 9, Opera 15-35, and Safari 5-9. The fix does not work for Safari ≤ 4.

Browsers using Presto and Trident treat monospace normally. Therefore, the monospace,monospace fix is not required for Edge 12-13, Internet Explorer 8-11, Opera ≤ 12.15, and Windows Phone ≤ 8.1.

Since they are checking explicitly for a computed value of monospace, other fixes may be applied, such as monospace,serif or _,monospace, if we feel one of those or something similar would be more readable.

@jonathantneal, awesome! Are we going to add this on the comments/docs?

This is all very interesting, but can anyone explain why the hack works? I thought comma-separated values for font-family were fallbacks; I never would have imagined that they would affect font size.

From @jonathantneal’s citation:

The solution above uses the value monospace,monospace, which works despite being logically equivalent to just monospace.

@chharvey others can correct me if I'm wrong, but I believe the suggestion is that some browsers have a hard coded check for font-family: monospace;and enable a hard coded fix for a class of font bugs. Due to the way this check is constructed, this isn't triggered if any other font is present, and hence you can override the fix by using font-family: monospace, any, other, fonts, go, here;. As monospace is a built in type, the other fonts are never reached in the fallback tree, and the intended font is applied. font-family: monospace, monospace; is used by Normalize because, while it is confusing, it's arguably less confusing that including other unrelated fonts, and it also GZIPs slightly better. I do not believe you do not need use this fallback if you are defining a specific font which you want to use, and so you can happily use font-family: MyCustomMonoFont;.

Was this page helpful?
0 / 5 - 0 ratings