For me one of the hottest things CSS3 has to offer is not an obvious one like animations or filters, but a pretty inconspicuous: the
rem unit. I recently employed it at a project for the first time and it really thrilled me. But one thing first, before I continue with my excitement. You know, these days it’s recommended to use relative units (like
em) instead of absolute ones (like
px), because the Web’s no fixed place, why should we use fixed units then?
Unfortunately the problem with relative units is, well, that they are relative. For one thing – and I’m speaking strictly of
em – they are relative to their parent. So if we have an element with a
1.4em, all the paddings you set in
ems are relative to this size, which makes the math very difficult (if you strictly relate to px units or the dimensions of another element). And moreover inheritance is a big problem. If you have an
<li> which is sized at
1.2em and nest another
<li> inside it, it effectively gets a
font-size of 1.2 × 1.2 =
1.44em. While the first can be helpful in some cases, say if you want the paddings always relate to their parent if things get enlarged, the latter is pretty annoying.
rem is the saviour
And here is where the
rem unit comes into play. This one’s not relative to its parent but to the root (therefore “r”em) of the document, so in most cases based on a
16px (which is the default for HTML documents nowadays – yep, even across browsers). Therefore every unit you want to be relative has to be divided by this factor to get the
rem unit. So if you want all spaces and sizes on your page to be consistent and only dependent on one factor (the document) and not numerous ones (their parents), this is the unit for you. I’ve set up a quick demo to depict this difference. The first
<h1> with the class of
.one is sized with
em, the second with the class of
rem (accordingly their paddings). If you change the
font-size of the first heading the left
padding grows or shrinks relative to it. Whereas for the second heading the
padding always stays the same – relative to the document. Not to mention that the
padding for the first heading is by far larger since it’s based on the heading’s size.
The same goes for the aforementioned nested lists. Please have a look at another demo. Since the
font-size for the
<li>s of the first list, with the class
.one, is set in
em, the nested items are double the size of the non-nested (remember 1.2 × 1.2 = 1.44). But for the second list the nested item remains at the intended size – therefore the same as the non-nested ones (list no. three –
.three – is for later).
Why should I bother?
The single most important question for you might be now: Why should I bother to size things in
rem and not just use
px? Well, let’s say you want to enlarge everything on your site as soon as it exceeds a certain width limit. With everything
rem you just set the
font-size of the
<html> tag to
110% and, magic, everything is 10% bigger. But what to do with everything
px in this case? Good luck with that! Make a media query and overwrite every single element, that is supposed to be larger? No way! Try it out yourself in the demo from above and change the
font-size of the
<html> tag. While the first and second list adapt, the third remains at the original size.
However there is one pitfall: the
rem unit is not supported by Internet Explorer < 9 (and Android 1.6, if you have to bother). But there is a relatively quick fix: for every property you use
rem, repeat it beforehand with
px values (remember, by default
px/16). A bit tedious, but the only way to
rem at the moment.
One thing last: the conventional
em unit still has its right to exist, for example for the measure (the line-length) of paragraphs, which are intended to adapt relatively to the font-size and nothing else. And like I said before, if you want
paddings that resize relative to its parent (and you don't care about actual pixel sizes or a relation to other elements). So, at the end of the day the
rem unit is a valuable tool in our tool belt to tailor device- and resolution-independent layouts. I love it!