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.

    • Stuart Suits

      Personally I don’t get the purpose of using a base size of 62.5% if you are aiming for relative control over layout whilst maintaining fluidity. Using a percentage at root relies on the premise that the user has not CHANGED the default font size in their browser of choice, a mistake which can blow out your layout, particularly if making use of nested divs or widgets. Personally I like to set html to 10px (we use metric for everything else so easiest to work with rather than the body font size of 14px) and use rem’s thereafter.

      At the end of the day, if someone needs to enlarge the text for accessibility, the zoom function enlarges the containers with the text which does more for readabilty in the long run anyhow….

    • David (Nirth)

      I don’t think 62.5 trick will ever be truly outdated. This trick permeates majority of companies I consult all the time.

      While I can admire desire to use REMs as intended, the simple fact is – REMs are specific to HTML, and HTML is only one part of a bigger pie. When designing applications for different platforms, it’s much easier to treat HTML as other platforms, and thinking in Pixels in this regard is much easier and comfortable.

    • Chris_Krammer

      I slightly changed my sight on this topic after I’ve read David Buell’s comment above (http://www.css3files.com/2012/10/11/relative-is-the-new-absolute-the-rem-unit/#comment-974000860).

      At a recent project I did it as he suggested and set the font-size to 62.5% for and to the desired font-size of the body copy at the . This way the maths are easier and 1rem = 10px.

      But I still advice everybody to stop using px. This way you can’t easily change all the font-size on a webpage with a single value like you can do it with rem.

  • 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.

  • MrB

    Hi there, your article states:

    “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?”

    but it is more than that – there are accessibility impliations for using fixed font sizes. They should be avoided. So I don’t think you should use 16px for IE “backup” (I know the site I work on wouldn’t pass an accessibility audit with pixels.) But to use ems returns the the problem you tried to avoid by using rems, and you’d have to style the entire site with ems anyway.

    Sigh. I will have to wait.

    As an aside, I’ve never really felt compelled to use the 62.5% thing, because the compunding effects of using nested ems destroys any clever em/px relationship.

  • David Buell

    Unless I’m missing something, isn’t this a better solution?

    Set HTML font size to 10px (for easy maths)
    Set BODY font size to 16px (or desired body copy for site)

    Then all ‘rem’ measurements will base off the 10px root size for easy math and you can avoid having to size the font for elements you want to use your desired body copy size.

    • Chris_Krammer

      This is basically the 62.5% trick, but only with px. But the addition of 16px (or 1.6rem) for the is a clever suggestion. This way you get easy maths on one side, since every value is based on 10, but apart from that you also get a basic font size of 16px. Will definitely try that out in a coming project.

    • olivvv

      This looked cool, I tried it. The issue I faced is that text resizing is not listened to anymore. Right now, in IE9+ world, I favor to only set the body in rem for your “main” screen size (assuming responsive webdesign). Then, with other sizes, changing the size with “%” on the body will scale up / down text in the whole interface.

    • Chris_Krammer

      Could you please make a quick example at CodePen or a similar service to showcase your approach? I’m sure we could learn a lot from it.

    • olivvv

      sure :
      ex 1. with 10 px on html tag : http://codepen.io/anon/pen/iewub
      ex 2. without : http://codepen.io/anon/pen/DjFtB

      —> setup a large default font-size (FF: press alt then tools>options>general)

      result: in the example 1, font-size is not scaling up.

      In fact I started a SO question about, but I am quite alone on it :
      http://stackoverflow.com/questions/19956490/rem-px-mediaqueries-for-browsers-ie9

    • Chris_Krammer

      With px you will just get problems with older IEs. Every “modern” browser should still be able to resize the whole interface if you use a px value for the tag and rems for all the other CSS values.

    • olivvv

      Hi again. I do not suggest using px.

      There is several types of resize:
      1. zoom
      2. zoom text only.
      3. permanent bigger font-size.

      I liked very much David Buell’s proposal, but it does not work with resize (3).
      Currently I think that the solution is (in my contextof IE9 as minimal browser and responsive design) :

      - html tag untouched for desktop size.
      - change body with “%” for other breakpoints if applicable.
      - set size on body tag using “rem”
      - set sizes of text-related stuff with “em” if it has too be proportional and otherwise rem. (see http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/ and http://jsbin.com/ehoben)

      But that is -in progress- in my mind, I need to do testing with different dpi – retina, improved pixel density on windows, etc

      So my current “solution” implies to do some math, which I consider far less difficult that handling Sass’s toem gone made, piles of elements having all font-size somehow modified. I experienced that in team work, and that’s unmanagable, I really want to avoid that type of situation.

    • David Buell

      I am looking in the latest Opera browser which supports permanent font-size changes (not zoom or zoom text) and when I change the setting the most recent codepen is affected.

    • olivvv

      Hi David. That was the purpose of the codepen, test both, text resize and zoom. However the codepen iframe blocks my breakpoints so the demo isnt the way it should be.
      (I have currently no internet at home but I hope to put that online somewhere else in the next week.)

      I did test ff/mac, safari/mac, ff/pc, chrome/pc.

      To my disappointment html{ font-size: 6.25%;}body{font-size: 16em;} does not work with webkit browser, because they have a minimum font-size. So we can’t have 1 rem == 1px (at standard size).

      but html{ font-size: 6.25%;}body{font-size: 1.6em;} works well everywhere.
      That provides 1 rem == 10px (at standard size), and that unit can be used to build the interface (essentially width of stuff). And when em are for the text, then the font-size can be increased and the interface react well (boxes extend downwards).

      Now that said, being in such “relative” context, it got me thinking. What is the main use of 1 rem == 10px ??
      okay I am used to think with px, but the main real use is to make border of 1px. Do we really want it to scale then and be 1.5px large ? I think that if the intend is just a thin border, then px can be used and maybe increased in a breakpoint.
      In comparison, having 1rem == 16px (or another size of the main text) has a strong use case. One can design relatively. Instead of having a 300px width box, we do a box with a size of 15 line of text. Building stuff relatively to the text is a real mindset change, but now I think that it is the most robust approach on the long run.

    • David Buell

      As to not interfere with browser zoom on non-modern browsers use 62.5% for the HTML font-size and then 1.6rem on the BODY.

      http://codepen.io/anon/pen/GFAky

    • olivvv

      Hi David. The issue I mentionned with html{font-size: 10px;} is font not scaling up, when the default browser size is changed (not the zoom), which is a setting I assume visually impaired user are likely to change.
      html{62.5%} solves this.

    • olivvv

      I made a little codepen to test all this with breakpoints.
      http://codepen.io/Olivvv/full/aGDzI

  • Artur Kwiatkowski

    As for the fix, LESS or SASS might be very handy if you need to support px values for older browsers. It is always better if you work with something like .font(32) and the logic behind .font() mixin is doing the job for you. Mixins are easily extendable so if you already have responsive project then I think you have minimum job to do.

  • tai

    thanks bro.. this helped me a lot with understanding how elastic layout works.. and relative values.. appreciate it..

  • http://www.allanwebdev.com Allan Luchenitser

    I’m a bit confused… I nested the elements like you said and did not get an increasing font size. Here’s a jfiddle: http://jsfiddle.net/alucheni/ng1e5rr2/1/

    • Chris_Krammer

      That’s because you didn’t write valid HTML (forget the around your nested s) and you didn’t specify a font-size for the s. See the updated demo here: http://jsfiddle.net/90bwy9pu/

    • http://www.allanwebdev.com Allan Luchenitser

      Wow thanks for the quick response. How often is this a problem? For example, I nested two p tags and didn’t get this effect. Is it specifically with li’s that are nested? Don’t feel obligated to respond if this is a deep rabbit hole.