Web typography

My take on fonts, page widths, and the light vs dark background debate
Created: 2018-08-04

My primary goal for Ratfactor.com is always readability.

Form follows function.

Content is king.

But how does one actually acheive maximum readability on a webpage?

Light vs Dark

Something that has fascinated me for a while is that websites are percieved as easier to read when they have a light/white background instead of a black/dark background. This is interesting because I, like many, prefer a dark terminal and text editor.

screenshot of my desktop
Figure 1. My desktop: editor on the left, browser on the right

This screenshot shows what you’re most likely to see on my desktop at any given moment: a dark text editor or terminal next to a light browser window. The browser is typically displaying the output of the project I’m working on or documentation. As I add more terminals, the browser shrinks on the right side, becoming a shrinking box of white on a dark screen.

Note
Naming convention
By the way, I see a lot of people using terms like "light-on-dark" and "dark-on-light" or even wordier descriptions. I find these painful to follow since I have to stop and think about them. Instead, I prefer simply speaking in terms of the background: "light background" and "dark background". Obviously we mean light text when we say "dark background", so why do we need to say it?

Either way, most folks agree that lower contrast is pretty may be pretty to look at, but high contrast is the way to go for readability. But then, if the contrast is too high, it can also be unpleasant for some folks (particularly white text on black background).

Which is best for reading?

On the other hand, studies have found evidence that light backgrounds are easier to read and that a light background helps the eye focus by having a less dialated iris. To further this idea, I’ve heard from many folks who find dark websites to be harder to read (at least initially).

The perception is that a light background is generally more readable for documents.

This is one of those cases where perception is reality.

So why do so many developers (such as myself) opt for a dark background for terminals and text editors?

Syntax coloring and highlighting

I have a theory about that: colors.

If you’ve ever tried to create your own color scheme for an editor or terminal application (and hey, who hasn’t, right?), you may have run into this: it’s hard to display different colors of text on a white background. On a dark background, you have the full spectrum of bright, primary colors. But on white, it’s hard to choose colors that stand out but are still contrast enough with the background to be readable.

Dark background (#222) Light background (#EEE)

stuff green stuff

stuff green stuff

stuff blue stuff

stuff blue stuff

stuff red stuff

stuff red stuff

Of course, like anything, this is subjective. But to me, the different colors on the dark backgrounds are not only more readable, but it’s far easier to differentiate between the three keyword colors. With dark backgrounds, we get the full spectrum of bright, primary colors shining out at our faces. On a light background, we can have to darken the text colors in order to make the text readable.

(In both cases, bold face fonts make a huge difference as well.)

This may explain the advantage of having dark backgrounds for tasks where being able to differentiate things quickly is an advantage such as programming and viewing the output of terminal applications.

Eye strain

Anecdotally, I’ve seen a lot of people who prefer dark backgrounds for working long hours staring at a screen.

Here’s a quote from the hyndsight blog:

"I spend much of my day sitting in front of a screen, coding or writing. To limit the strain on my eyes, I use a dark theme as much as possible. That is, I write with light colored text on a dark background. I don’t know why this is not the default in more software as it makes a big difference after a few hours of writing."

And from an answer on this Stack Overflow question:

I find black backgrounds to be extremely comfortable on my eyes even for very long sessions, but white backgrounds are very fatiguing. I have heard it described as "staring into a 100 watt lightbulb" and that’s how it feels to me.

For what it’s worth, I feel the same way.

I haven’t been able to find any reference to actual studies in which light backgrounds are more of a strain on the eyes over long periods of time. But various anecdotes and my own experience says that staring at a bright screen with a lot of white (particularly in a dark room) for long periods of time feels fatiguing.

So perhaps light backgrounds are better for general readability, but somewhat harder on the eyes for all-day use?

What most people seem to agree upon is:

  • 100% white or black backgrounds and text can be harsh

  • Contrast that is too low is a serious problem for people with various vision problems.

Light vs dark: it depends

Ambient lighting can clearly be a huge factor: I’ve tried using laptops outside in which my favorite dark background themes were completely unreadable. But when it’s dark and you’re trying to preserve your night vision, it’s well known that dark backgrounds (particularly with red text/graphics) are the most effective and are the least stressful for your eyes.

Screen technology can make a huge difference. CRTs are very different from LEDs which are very different from projectors, e-ink, etc.

There is no one-size-fits-all.

Some folks swear they can’t read text on dark backgrounds. Others get headaches from light backgrounds.

Check out all of the opinions on this Stack Overflow question.

Or here’s a quote from this Slashdot discussion from 2008:

"It’s weird, but I do better with light text on a dark background when coding, and vice versa with documents and technical web pages most of the time."

That pretty much describes me.

Font size

Browsers seem to default to a 16px default font size. I find this to be quite readable.

This Smashing Magazine article from 2011 suggests a 16px minimum font size. At the moment, the article itself is being displayed with a 21px font size (computed).

Wikipedia uses a font size of 0.875em which computes to 14px in my browser. The mobile version of Wikipedia has a font size of 100%, so that’s 16px in my browser. With a text color of #222222 on pure white in both views, I find Wikipedia quite readable for its intended use.

I frequent Hacker News quite a bit. It uses a quite small font at 9pt which works out to 12px in my browser. The text color is pure black. HN has a pleasant gray background color (#828282).

Stack Overflow has a font size of 15px and very dark blue text (#242729) on a pure white background.

At the moment on Ratfactor.com, I’m opting to go with the browser default by not setting a font-size at all!

Width of text

Most folks seem to agree that there is an ideal maximum width (or number of characters) for text. Nobody agrees on exactly what that amount might be, of course, but they do agree that there is one.

There’s a fantastic answer to this UX Stack Exchange question with some rules of thumb and great general advice:

Additionally, you may want to be very conscious of your content size. For longer content prefer longer lines; with short content prefer shorter lines. Typically take the size of paragraphs and sections in your content as variable to how long the line should be—you don’t want 1-line paragraphs, but equally you don’t want 30-line paragraphs. Choose a happy average that makes the content easy to visualize.

I think this is a great point. Not all written content is the same.

Almost every site I visit these days has a maximum width for written content. Wikipedia is the big exception, but I find myself strangely unbothered by it.

Let your content flow!

There’s only one thing I really can’t stand: sites with fixed widths! Please, for the love of all that is good, use max-width and not width when defining your main content area.

I rarely browse with my browser in fullscreen mode (see the screenshot at the top of this post). It’s not as small as a cell phone, so it often doesn’t trigger a "mobile" view.

If I have to scroll horizontally to read your content, I’m not going to stay very long unless your content is really, really valuable or if you are displaying a large table or something else which justifies the width.

By all means, set a maximum width so that your text doesn’t stretch all the way to the ends of the earth on today’s widescreen monitors.

But don’t set a (minimum) width. As long as you don’t, Your text will flow beautifully from the biggest desktop down to the smallest phone and every size inbetween. No need to do media queries or set breakpoints. The browser has been capable of doing this for you for decades. It’s one of the few things it’s always been good at. We just often don’t have the sense to step away from the CSS and let it!

Font family

I’m starting to get a little crotchety about using web fonts (via CSS @font-face) on pages and small web applications.

I like the Google Fonts library. It’s a great resource and a lot of people have made some really beautiful websites using those fonts.

But there’s two problems:

First, I am generally against the Bullshit Web and any form of bloat that doesn’t contribute to the content of the Web in a meaningful way. I love typefaces. I really do. But I hate waiting for them on slow connections when all I want is some quick information.

Another problem I have with them is that they’re another impediment to being able to work locally. I had a really spotty Internet connection a couple months back. It forced me to work locally as much as possible. External web fonts made it a total pain to view static HTML documents.

Web fonts are here to stay and I don’t hate them. But please consider not using them unless you have a compelling reason to do so.

Ratfactor.com uses font-family: sans-serif so that your browser can use what it believes to be its best font face to view my text. Neat, right?

Ratfactor styleguide

Here’s what the most common elements look like.

Heading 3

I mostly just use two levels of heading. That seems to cover the needs of most article/post-sized pages.

Heading 4

Some longer articles, particularly technical documentation do work better when you have four heading levels. Beyond that, maybe you’re breaking it up just a bit too much?

Note
This is an admonition block.

Have you ever read one of those auto-generated HTML documents that puts every little heading into its own page so that you have to keep hitting the 'next' link to read another stinking paragraph of text? Ugh.

  • A list

    • With sub-items

    • Like this

  • And such

Literal blocks are good for code samples, command line examples, and poems.

Word frequencies in Nim
var wordFrequencies = initCountTable[string]()

for line in stdin.lines:
  for word in line.split(", "):
    wordFrequencies.inc(word)

I’ve already used a number of block quotes in this post:

"If I have to scroll horizontally to read your content, I’m not going to stay very long unless your content is really, really valuable…​" -Dave

It is also handy do be able to insert notes into documents. Especially for me, since I’m so prone to tangents. Mind you, I actually enjoy tangents, so I don’t consider this to be a major failing.

Note
Speaking of tangents, the science fiction short story titled Tangents by Greg Bear won the Hugo award in 1987. I read the story in a collection also titled Tangents when I was in my late teens.

And I’ve also used a table already.

Col 1 Col 2 Col3

a

b

c

1

2

3

red

blue

green

And finally, I do have some forms as needed:




I’d say that about covers it. Do you have a differing opinion or suggestions about the styles used by this site? I always welcome feedback!