This article was written in 2014. It might or it might not be outdated. And it could be that the layout breaks. If that’s the case please let me know.

The weird 62.5% antipattern

There’s always been a problem with using the em on the web. The core of this problem is that there is no option in Photoshop to use the em as a unit. That’s really the only reason we use pixels. We have to use them in Photoshop. This pixel-thinking has influenced our em-thinking. Many developers use calculators to turn pixel-values into em-values. And thus we turn a pixel-perfect photoshop template into a pixel-perfect, but fluid website. But turning pixels into ems is hard. They don’t really match. They result in crazy numbers. There is a very clever hack that tries to solve this problem. But, as with all hacks, it creates new, worse, problems.

62.5% is equal to 10px, usually.

If you set the font-size on the html element to 62.5%, 1em is suddenly equal to 10px. This is of course much easier to work with. You inspect some text in photoshop, see that it’s 13 pixels, and type font-size: 1.3em; into your text editor. If you don’t use this trick you’d have to divide 13/16. Which is 0.8125em. This is hard. So this hack definitely makes sense. The problem is not so much with the idea behind this trick, the problem is with inheritance.

We need to set every element’s font-size

Since we set the font-size of our html to a tiny 10 pixels, we need to set the font-size on every single element. If we want our body copy to be 16px we have to do something like

p, li, td, input, button, label {
    font-size: 1.6em;
}

This turns into a nightmare when you have to nest elements. For instance a p inside a li. This p is now 1.6×1.6em. So in order to fix this we have to do something like this:

li p, label input, li label, td li {
    font-size: 1em;
}

Which is crazy.

You could of course use rem instead of em to prevent this terrible inheritance mess. But I explain in a previous post that the rem is not flexible enough for font-sizes.

How to solve this

This can easily be solved by not setting the font-size on the html element to 62.5%. Instead we simply set it to the size of the body copy. For instance 100%. Now we don’t have to declare the font-size for every p, li and label, and this means we don’t have to declare all these terrible inheritance instances! Problem solved. And it helps us in solving a bigger problem. Pixel-think.

The reason this mess exists in the first place is because we still think in pixels. This can be easily solved. Instead of defining our typography with an absolute unit like the pixel, we can better design our typography as a scale, as a ratio. This way it doesn’t matter how many pixels we’re talking about, because it’s the scale that matters. And it doesn’t even matter how big the body font-size is, because this scale works at any font-size. Take a look at this example. There is a very clear contrast between the different heading levels. An h2 is clearly smaller than the h1. But how big are they exactly? To be honest, I don’t know. It depends on the size of the viewport of your browser.

Using a scale, instead of absolute units

The exact font-size of each element in our example depends on a few factors. The most important one in this case is viewport size. On smallish screens the font-size on the html is 100%. So 1em is probably equal to 16px. The h1 has a font-size of 3.998em, which looks like an insane number, but which is actually 1.414×1.414×1.414. And no, I didn’t calculate these numbers, I used a nice, simple, visual tool to generate these numbers for me. Now, how big is 3.998em? On a smallish screen it’s 63.9667px. On a mediumish screen I set the font-size on the html to 120%. And on a biggish screen to 140%. How big are all these different headings on all these different screen sizes? The answer is: it doesn’t matter. The exact sizes are different all the time, but the ratio is still the same.

A system

What we created here is not a pixel perfect design. What we created here is much more. It’s a very flexible, but simple design system. We can easily adjust this system, or parts of this system, to the different needs of different devices. In this case I assumed that bigger viewports benefit from bigger font-sizes. Which is probably not always true. But it clearly illustrates my point. If we get rid of this rusty pixel-thinking, we don’t need silly 62.5% hacks, and instead we can design simple yet flexible typographic systems.