Relative is the new absolute: the rem unit

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 font-size of 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 font-size of 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 .two with 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 rem = 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 margins or 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!

  • Allison Beh

    Good read. I’ve been using px since the day one I learnt CSS and though I came across with em from time to time I was reluctant to step out of the comfort zone to try it out. I see the beauty of rem in responsive design. And boy I actually changed the size of the elements in px one by one in the media queries of my first responsive web design (published last month)! I’ll squeeze out some time to convert the unit to rem in my stylesheet, as a start.

    Still I have a question: like em, px does have its right to exist, right? For example in fixed-width layout.

    Thanks Christian for the rem explanation.

    • http://www.css3files.com Christian Krammer

      Yeah, you should really take the time and change all the values from px to rem. It will be of worth.

      > Still I have a question: like em, px does have its right to exist, right? For example in fixed-width layout.

      There aren’t, respectively there shouldn’t, be fixed width layouts anymore. They are against the nature of the web. Whenever possible use rem, px is only for content, that always needs to have the same width (like certain images) or elements, which need to have a definitive distance, but they are rather an exception. In 99% of cases you can/should use rem or em.

  • http://laukstein.com Binyamin

    Improve your CSS font-size rem measure with


    html {
    font-size: 62.5%;
    }

    beside of 100%. After 14px will be the same like 1.4rem.
    IE still have issue with it, so you can’t jet use html { font-size: 6.25%; } and after 14px and 14rem (they will not be in the same size even on IE10).

    • http://www.css3files.com Christian Krammer

      I’m sorry to contradict, Binyamin, but the so called “62.5% trick” is outdated and shouldn’t be used anymore. Instead set the font-size for the tag to the desired size of your body copy. But since 16px is a pretty good size leave it at 100% and – if needed – only set the font-size for the individual elements.

  • Robert

    I don’t understand, why is 62.5% considered outdated? I couldn’t find any further information on that, and the big upside of it is that rem and the fallback px values are now on the same scale, instead of some weird “x/16″ decimal value.

    E.g. 15px is 1.5rem vs. 15px is 15/16= 0.9375rem.

    Can’t see any benefit in that, so I’d really like to know the reasons for it to be considered outdated.

    • http://www.css3files.com Christian Krammer

      Because a much more “sensitive”, adaptable way is to leave the base font-size at 16px (= 1em respectively 1rem). There is no reason in setting the base font-size to 10px only to set it back to 16px for the paragraphs (respectively the body copy of a website) only to make the calculations easier. Because 16px is pretty good default size for large portions of text on a website.

      Apart from that there is really no reason anymore to think in pixels. Does it really matter if a font is 16px, as long it is readable? So there is also no need to convert everything into the the decade system, because you can also set widths, heights, margins in rems. That’s especially important for responsive layouts.

    • sp00n82

      Sorry, I have to disagree here.
      I for one have _much_ easier time guesstimating a margin of e.g. 22px (or 2.2rem) instead of something like 1.375rem… Your mileage may vary, but I have developed a pretty good feeling for the pixel-to-space ratio in the meantine, and I think you’re just making it needlessly complicated by _not_ resetting the base unit to 10 pixels.

      Sure, there may be occasions where you don’t have to adhere to single pixels at all and can just freely space the elements to your will, but most of the time there will be more or less prerequisitions that will drive you back to “pixel-thinking” again, be it one way or another.

      Also, regarding font sizes, you still have to fall back to pixels to support Internet Explorer <9, which means you cannot simply ignore those pixel defintions alltogether (except if you're not publishing for the general public that is, or don't use rem but em, but that's not what this article is about). Which means, until IE8 shares the fate of IE6 (which FINALLY doesn't play a part in design decisions anymore! Happy days!), it just doesn't make sense to rely on rem only. You just HAVE to use pixels as well.

      So, why make it more complicated than needed by using a divisor fo 16 instead of 10?

      We could argue about directly setting the font size to 10px instead of 62.5% though, as the default font size in the user's browser may have been changed away from 16px, but AFAIR this caused other IE issues.

      It's possible that with time IE8 will become obsolete and we're all so familiar with a default 16px size so that we all can design without having to think twice, but right now I just don't see that happening too soon.

    • Chris_Krammer

      What I said above still remains and there is not much to add. I hope we don’t need to argue about the fact that relative units are almost essential in times of responsive design.
      Regarding the base font-size there may be different tastes: one likes to set it to 62.5% so that the calculations are easier, others (the majority I bet) likes to set the base font-size to the desired size of the body copy, since that’s the most important part of your site. There is no right or wrong here I have to admit.

    • wayne23

      I don’t get your arguments, the 65,5% trick “is outdated” you make no sense and do not back your claims up. Thinking in pixels is so much esier and cleaner. Because of ems? What about this? There you have your base 16px font size and your em that work just as theiy were all the time. Even in old browsers that not support rem.

      html {
          font-size: 62.5%;
      }
      body {
      font-size: 1.6em;
      font-size: 1.6rem
      }
      

      You just make no sense. I mean who is not thinkign in pixels? Everyone is thinkign in pixels! Even if you may trained in think in rems you always think calculate unconciously and always refer back to pixels.

      10px = 1rem has only benefits and no negative downsides I can think of. Am I missing something here or what?

      Oh yeah but is so conveniet and great to devide every freaking value to 16, 14 or whatever that can be very easy if your using LESS or SASS but still it makes no sense you end up in some long ugly numbers.

    • Chris_Krammer

      Why so aggressive?

      Apart from that there is really nothing more to say for me. I’ve made my points in large detail, but one thing just for you: Why is there a need to change the base font size of 16 pixel – which is a pretty good size for body copy at a site – only that the calculations are easier? Does it really matter if a margin is 16 pixel or 1 rem? And like I’ve said before: I wish you much fun if you need to enlarge the whole site at a “wider” media query with everything set in pixels. Do you want to adapt every single value?

    • wayne23

      So you like to have a hell of a lot values like “0.9375rem” as a equalient for 15px as Robert in your css just because you are to stubburn to include a this sizes on the body and html? Yeah that makes so much more sense. In the end you end up with more CSS and need to calculate everything since images and special elements are still in px.

      “Does it really matter if a margin is 16 pixel or 1 rem? And like I’ve
      said before: I wish you much fun if you need to enlarge the whole site
      at a “wider” media query with everything set in pixels. Do you want to
      adapt every single value?”

      First yes it very well matters if a margin is 16px or 1rem because rems resize with the users font setting and then the 1rem margin will resize as well and look better becasue it fits togther with the font resizing. And what you said afterwards I don’t get it, You speak to me as if I have everything in pixels or arguing for pixels? Wtf are you saying? How does this relate to the “65%” thing? It simply does not. I think you are stupid.