By Harry Roberts
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Written by Harry Roberts on CSS Wizardry.
Jonathan Snook wrote recently about the new font-sizing unit rem
. Whilst I do find it interesting and potentially useful I do think it possibly solves a problem that doesn’t actually exist…
N.B. This article isn’t a response to Jonathan’s, nor am I calling him out, he just happened to have laid some nice foundations with his article that allow me to use it as a base. It is worth noting further that Jonathan a) uses px to declare font-sizes anyway and b) does start with the base he intends to use. This article isn’t a response to his.
Jonathan uses the example:
body { font-size:62.5%; }
h1 { font-size: 2.4em; } /* =24px */
p { font-size: 1.4em; } /* =14px */
li { font-size: 1.4em; } /* =14px? */
li li, li p /* etc */ { font-size: 1em; } Here he sets his base font-size to 10px then creates a `h1` size of 24px, `<p>`s and `<li>`s of 14px and then children of `<p>`s and `<li>`s at 1em, also 14px.
Here is a problem that developers continuously cause themselves. It’s clear here that, although he sets a body font-size of 10px, the actual base font-size is 14px. Therein lies the problem.
Creating a base font-size that you don’t actually need means you have to redefine nigh on every element to take on the size you do want–you’re creating a rule that you don’t even want and it’s causing you work…
If you want your base font-size to be 14px then set your <html>
at 0.875em
and you’re done. If you want a 24px <h1>
then your CSS is simply h1{ font-size:1.714em; }
.
The 62.5% trick is a common one, and does have its uses in two circumstances:
width:30em;
== width:300px;
)If you are doing neither of these then be kind to yourself and set the base you actually want.
The main reason people reset the font-size to 10px is point one; to make maths easier. If your quasi-base is 10px and you want an actual base of 12px it’s simply 1.2em. The maths is easier, we can work with units of ten more easily, but that comes at the cost of maintainability.
If you set your quasi-base at 10px and you want your body copy to be 12px, you have to style every single element that falls under ‘body copy’ individually. Hence Jonathan’s giving font-sizes to list items and paragraphs. This means you’re writing more code than you need and also leads to nasty inheritance problems; problems that rems are supposed to fix. A <p>
in an <li>
will be 1.2x12px, whereas it still only needs to be 12px.
If you were to just set your base at 12px in the first place (body{ font-size:0.75em; }
) then:
The main reason, I feel, behind using the 62.5% method is laziness, and that’s a good thing. Good developers are lazy. However that laziness is misguided; it’s actually causing you more work. You have to define font-sizes on all elements rather than just once and letting them inherit and you have to tackle those horrible inheritance issues when an explicitly sized element is placed inside another one.
When setting the base font-size correctly and only once the maths isn’t as nice, I’ll admit. With the 62.5% trick a font is an even ten times its em unit (2.4em = 24px, 5em = 50px and so on). With setting your base to what you actually want the chances are you will end up with a not-as-nice number. If you want your base to be 16px then 2.4em = 38.4px, 5em = 80px. It’s a little more work in your calculator app, but it’s a lot less work when it actually comes down to build.
CSS Wizardry has a base of 16px, so I just leave it at font-size:100%;
. 16px is the rule, headings are the exception. As such I only need to redefine font-sizes on headings.
My maths is a little harder, my coding is a breeze…
So by all means start using rem
s, they seem pretty interesting, but it may just be solving a problem you don’t even have…
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I am available for hire to consult, advise, and develop with passionate product teams across the globe.
I specialise in large, product-based projects where performance, scalability, and maintainability are paramount.