Browsers and the relative size of their default monospace fonts

December 17, 2019

One of the unusual things about Wandering Thoughts and all of my web stuff is that it's almost completely unstyled. In particular, I don't try to specify HTML fonts or HTML font sizes; I leave it entirely up to your browser, on the assumption that your browser knows more about good typography on your system than I do. However, this doesn't mean that my entries live in a pure world of semantic content, because in practice you can't divorce content from its presentation; how Wandering Thoughts looks affects what and how I write. One of the consequences of this is that I end up making some tacit assumptions about how browsers handle default fonts, assumptions that may no longer be correct (if they ever were).

Following a convention that I believe I coped from Unix manpages, I often write entries that intermix normal non-monospaced text with bits of monospaced text, which I use for a whole variety of things ranging from code snippets through Unix commands and filenames or just things I intend as literal text. This is a reasonably common convention in general, but when I use it I'm implicitly relying on browsers rendering normal text and monospaced text in something that is the same size or reasonably close to it. If a monospaced word is either tiny or gigantic compared to the normal text around it, the two no longer combine together well and any number of my entries are going to look weird (or be hard to read).

Unfortunately, it increasingly seems like browsers are not doing this and that they often have their default monospaced font be clearly smaller than their normal text font, sometimes noticeably so. This is of course platform dependent, and I think that common platforms still have the two fonts sufficiently close together in size that my entries don't look glaringly wrong. But I don't know how long that will last or how true it is for people who've tried to change their browser's default size (to make it either bigger or smaller).

If mixing normal text and monospaced text is increasingly risky, this is going to affect what I do here on Wandering Thoughts in some way or another. Most likely I will have to start moving away from mixing monospaced words into my regular paragraphs and confine them to their own out of line sections.

(This is a good part of why I care about Firefox's peculiar handling of font choice preferences. By default Firefox's monospaced font size is too small for me, especially once I adjust the size of its regular font.)

As a side note, this isn't just a browser issue, unless you take an expansive view of browsers. I also run into this in my syndication feed reader of choice, which of course also has to render HTML and also has to chose default sizes for normal and monospaced fonts. Compounding the issue, these programs often give you less control over fonts and HTML rendering in general than browsers do.


Comments on this page:

From 193.219.181.226 at 2019-12-17 02:38:33:

I guess the issue is that monospace fonts already look gigantic compared to (sans-)serif ones at the same 'pt' size – no matter whether they're in an HTML document or not. It seems that if the general style for <p> is to have 12pt text, then <code> has to be ~10.5pt to match.

So with a completely unformatted monospace tag, the browsers I have here seem to over­com­pen­sate and default to 9pt – which is slightly too small compared to sur­round­ing text, but still looks okay with all fonts I've tried (monospace being wider kinda makes up for the difference).

However, I don't think I could actually call it "tiny" – except perhaps on mobile browsers where the phone-friendly view throws everything out of whack in general.

Still better than the obnoxious "chip" style which many modern templates use, some of them having completely mismatching colours to the rest of the page. (If the whole page is white-on-black, at least they could have the decency to not format <code> and <pre> as black-on-white...)

If people are using software that significantly deviates from the normal expectations, you can’t cater to them. Their experience on the web would be similarly inconsistent across all sites they visits, and they should blame their browser vendor. If every site changed how they do things to accommodate the oddities, it only empowers people to keep doing non-standard things.

Written on 17 December 2019.
« Some pragmatics of blackbox and whitebox malware filtering
PCIe slot bandwidth can change dynamically (and very rapidly) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Dec 17 00:18:24 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.