This article was written in 2013. 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.
Why I dislike the rem unit
There are a few serious issues with the rem unit. The main reason why I dislike the rem unit is because pixels don’t belong on the web. Yes, that sounds weird, but let me explain. If you define font-sizes with pixels people who use certain browsers can’t increase their font-size. This conflicts with the idea that the user should be able to override styles with their own preferences. I think that idea is one of the things that makes the web such a wonderful place. That’s why I dislike pixels. But what does that have to do with the rem?
The rem unit needs a fallback
The rem unit is clever, in principle. The reason people use it is because we’re used to counting with the decimal system. If we do something like this — html { font-size: 62.5%; } — which sets the font-size to 10px in most browsers, it’s easier to define font-sizes set in Photoshop. If a heading is 22px, we can now easily define it like this — h1 { font-size: 2.2rem; }. Nice and simple. There are a few problems though. The first one is pixels.
Unfortunately rems are not supported on certain (older) browsers. For these browsers it needs a fallback. People use pixels as a fallback. The heading now looks like this — h1 { font-size: 22px; font-size: 2.2rem; }. Older browsers will ignore the second font-size rule, and newer browsers will override the first one. This means that people with older browsers will not be able to resize the font-size to their preferences. This is a problem for everybody who’s older than forty. If you’re not forty already, you will be one day, probably.
So instead of using pixels as a fallback, you should be using em as a fallback. But if you use em as a fallback you don’t need rem, because ems are just as flexible as rems. And if you think about it, they’re actually much more flexible than rems.
The rem unit is not flexible enough.
Flexible units are great for responsive design. A common pattern in responsive sites is that the font-size is smaller on a smaller screen. We can do this by simply reducing the font-size on the html-element. Now all font-sizes will be smaller, but the ratio between the font-sizes remains the same. This works with rems and with ems.
html {
font-size: 62.5%;
}
h1 {
font-size: 2.2(r)em;
}
@media (max-width: 20em) {
html {
font-size: 56.25%; /* this will result in a smaller h1 */
}
}But what if we decide something else. We might want the text in an aside to be smaller than the body copy on bigger screens. A quite common pattern too. With ems this is very easy.
@media (min-width: 20em) {
aside {
font-size: 90%;
}
}
With the rem unit we have a problem though. Since all font-sizes are relative to the root element, the font-size: 90%; rule is completely ignored. We now have to recalculate and override every font-declaration in the aside to get the same result. Spaghetti is wonderful as lunch or dinner, but not as code.
The rem unit is buggy
So by using the rem unit we disable the flexible nature of the web for some users, and we write code that’s not as flexible as it should be. If this is still not enough reason to ignore this unit, here’s another reason. It’s buggy. I assume this bug will be fixed soon but right now this unit seems a bit too fragile to use in production.
Yes but inheritance is hard!
Another reason why some people prefer rem over em is because inheritance is hard. I always tell these people they’re doing it wrong. This sounds a bit harsh, so let me explain. What is this inheritance problem? Imagine a website where we want the font-size of paragraphs and list items to be 12 pixels. Here’s one way to do this:
html {
font-size: 62.5%;
}
p,
li {
font-size: 1.2em;
}
The inheritance problem occurs when we nest a p in a li. The p will now be 1.2 × 1.2 = 14.4 pixels. This is too big. To make sure that a p in a li is 12 pixels too we now have to write extra, increasingly complex code:
html {
font-size: 62.5%;
}
p,
li {
font-size: 1.2em;
}
li p,
li li {
font-size: 1em;
}
This problem gets bigger if we define font-sizes on elements that usually contain more child-elements, like on a div, or on sectioning elements.
I think this problem is caused by the fact that we want to calculate font-sizes with our decimal system. Once we let go of that burden we see that it’s actually pretty simple and sensible to prevent this inheritance issue. Instead of setting the size of the root element to something that’s easy to do maths with, we set it to the actual size of the body copy. That’s the size of the text you’re reading right now. This way we don’t have to declare font-sizes for every element. This solves the inheritance issue. And it results in much cleaner code. This next block of code does exactly the same as the complex example above
html {
font-size: 0.75em;
}
So using ems forces you to think about structuring your CSS. This is a good thing. It results in less code, and more robust CSS. And the result is much more flexible.
Round numbers are not flexible enough for proportions
If we look at each heading as a separate element with a single font-size it makes sense to use pixels, or rems. But if you look at each heading as one step in a scale, as one part in a system, suddenly pixels are not flexible enough. But even if our designer just picked some random sizes that look — or feel — good together, turning them into ems makes sense. They too will turn forty, so they too will want to increase the font-size one day. Even a scale of randomly picked sizes that look good together will still feel right when the base font-size is increased.
Superflexible
Now if we decided that the font-size should be larger for bigger screens, a simple html { font-size: 1.1em; } would do. The ratio hasn’t changed, but all fonts are bigger. And if we decide that all typography within an aside should be smaller, a simple aside { font-size: .618em; } would do. Same ratio, different font-size. Simple. Do we know how big each heading is, exactly, in pixels? No we don’t. But does that matter? No, not at all. We might not know how big each heading is exactly, we do know that everything is in proportion.
But why?
I wrote this article because this morning I told someone he’s doing it wrong
, which is pretty harsh. I can now apologise and send him a link to this article. Again, he’ll read he’s doing it wrong, bit this time with an explanation. Sometimes 140 characters are not enough to explain something. Next time, instead of just telling someone off on Twitter, I’ll have a link with an explanation to accompany it.
Nice summary of relevant factors to this problem!
I’ve been having this discussion for ages now, and I’m really wondering what those “certain browsers” are, do you have an exact list? I’d like to see some research there, because somehow I have a feeling this problem either died with IE 6 & 7 and the introduction of browser-zoom.
But let’s face it; designers are not perfect, and unless there’s some epic typography with relative font-sizes in a design, this is still a problem. I think this problem can only *really* be solved the moment designers are thinking with em’s. Let’s educate :)
Unfortunately I still disagree for now. I personally have more problems with various unreadable decimal places to define a font-size than I have with the in my opinion very small disadvantage of not having a browser-resizable font-size. Those unreadable font-sizes are reality now.
the rem unit can also be used for other things. For instance if you have a box with an increased or reduced font size, but you want to have the default (1em) margin, you also might use 1rem, or am I totally wrong?
I haven’t used this yet, but this might be useful.
@Bran it’s not so much about the ability to zoom, as it is about the ability to set a larger default font value in your browser. For instance, open up this codepen and set your browser font-size to something bigger than 16px http://codepen.io/anon/pen/eKDIo
Example with a modern browser is Chrome: set the font-size in your advanced settings to “big”. See how you’re still serving a smaller font-size to users (with impaired vision) that use this feature?
Second: CSS pre-processors already pretty much solved the problem of unreadable font-sizes. Take a Sass example where I’ve set my body font-size to 100%. Then using font-size: 21/16*1em; on any given element is pretty readable imo.
@Xavier: I know about the default font-size value in the browser, but my point still stands. My first question is partially answered: current Chrome. Do all the modern browsers behave like that?
And what user does that? Nobody can show me numbers, and I personally don’t believe it. I’ll make it worse: what end-user even knows about this browser setting? I think since browsers have the zoom feature (which is very prominent in some browsers), people are way more likely to zoom than increase the default browser font-size I think, also since that probably won’t work on most sites, and they’ll have to zoom anyway.
About CSS pre-processors: you’re perfectly right! It doesn’t solve the nested example, but it saves looking at unreadable decimal numbers.
Same thing happens in Firefox. Some (older) stats are pretty easy to find: http://www.oreillynet.com/xml/blog/2006/03/more_statistics_on_user_clicks.html.
That article is pretty old, but it still stands. Also, I would expect the Chrome and Firefox teams to remove underused features from the interface, based on their history removing things like RSS auto-discovery. Granted, it’s not as good as hard statistics, but it’s good enough for me. Even if I make those three people happy that use it.
Allow me to do the longform version of my Twitter comment :)
If you can’t read the text in your browser comfortably, you can zoom in using the page zoom function of your browser. On a tablet you can zoom in by pinching. These functions have existed for years. It’s annoying to do this for every site if you have bad eyesight.
It’s better if the designer chose larger type by default so you don’t have to zoom in.
Now, the implication if can’t read most browser paragraph text (13-16px) comfortably is that you also can’t read the text in your OS comfortably. You could argue that most of the OS is not about reading but I would just tell you about Microsoft Office then. There you will have to use similar zoom functions as in the browser to compensate for your bad eyesight.
If you have bad eyesight you could maybe set a minimum font size in your browser like you did. The problem is that this setting “muds the water”. By this I mean that a paragraph that was typeset to be spaced to 45-65 characters for a comfortable reading length is now suddenly kess than 45 characters. So you are seeing a different design than was intended. It’s OK, we have to let go on the web, but nobody can account for all variables.
The objective for a web developer when coding a website is to get it done. Responsible web devs will code using progressive enhancement and test for accessibility but the nature of the web (and human nature) implies that most sites – won’t – be built this way.
We can have all the theoretical discussions we want about what unit is best. People will always default to the path of least resistance. Should every web dev go throug the pain of coding ems and rems? I don’t think so. The scaling and zoom levels should live in the browser. It’s up to the web dev to use liquid units to codify what they’re “intending” to display. Then the browser can render what they want based on both this codifying and the user settings.
It would be better to have the user solve the problem globally (i.e. by getting better glasses, a larger monitor, setting a default browser zoom, setting Windows settings to 96dpi instead of 72 so everything is larger, etc.). For me the problem set of zooming and legibility is on the OS and hardware level.
Trying to solve it on a website level is very noble – and don’t get me wrong, I try to code my stuff responsibly to do just that – but ultimately you’re building a more accessible car when we need more accessible highways.
Thanks for your lengthy comment, Johan. There’s a thing I don’t understand in your comment, and I think it’s the core of your argumentation. You write
This is actually not true if you use the em as a unit. Not just for font-sizes, but you should the em for all sizes, really. And especially for your mediaqueries. If you define your mediaqueries using pixels, things will definitely break, as you describe. But if you’re using ems, like you should, the whole layout will simply scale if the user prefers a bigger font. This is actually the only way to have some control over how things look.
And just because other software, like Office, isn’t as flexible and accessible as the web doesn’t mean we should emulate bad behaviour. We can do better on the web, much better. So we should.
And as I wrote, it’s not just about accessibility. It’s also about keeping your design flexible, so you can easily change it for different environments. This too is unique to the web. Operating systems and native apps run in a much more controlled environment. The web, as you know, has to run everywhere. If using an em, instead of a pixel or a rem, makes this easier and more powerful, I see no reason to stick to the other units.
About the paragraphs – you are right – this was an oversight in my comment. I should have known because on our new website we’re using em based media queries combined with the rem unit.
The rem unit has been a godsend to be able to globally control font size (and subsequently all sizing since we use rems for -every- unit) across responsive websites (i.e. make everything a tad bit smaller on a small breakpoint).
However, I think I’m a special case that goes on to research every bit of what makes a website a good website and I don’t think the majority of websites will ever conform to “what you should ideally do” (that is, em as the only unit, WAI ARIA all over the place etc.).
People are lazy, this is even a statement about yourself in your bio. So assuming it’s “not gonna happen”, the root of my argument is that the pain of dealing with scaling should be solved on a software/hardware level on a higher level than a website itself, meaning that the OS (or browser) should have the right zoom/scale capabilities, and that the user itself needs to fix their settings so that “their” default feels right.
@Wolf (or Johan in a previous comment) Seems we are in complete agreement here (-: You should always use ems, agreed.
And people should be able to set their preferences, and sites should still look good. And we also agree that the browser should translate these settings to something that looks good. This is already what browsers do. And the tools to make this happen are relative units like the em and percentages.
I’m not sure what laziness has to do with it though. The fact that I’m lazy would be proof that lazy people prefer ems over pixels or rems. I can only conclude, in that case, that people are *not* lazy (-:
I think it has to do with the fact that designing flexible sites is still pretty new to many people. Not every aspect of a fluid web, and the flexible units, is completely understood by everybody, yet. It will be one day though. We just have to explain it a few times more.
I understand Johan’s point of view though: if you would analyse and count the relative amount of sites that do not use em’s, it might make more sense to change the browser behaviour to also zoom pixels.
After all, a pixel is/has become a relative unit too.