By Russ Weakley

CSS3 rem units

By Russ Weakley

Supported by all modern browsers, the CSS3 rem unit allows font size and other properties to be specified against the root element, not just the parent, as is the case for the em unit.

In this short five minute video, I’ll give you a succinct overview of what rem units are, their advantages compared to other units, and how you can use them right now.


  • TaoistTotty

    There is a mention of links in the text/comments in the video, but there are no links.

    • Michał Czernow

      Watch the video on YouTube. In video description section you can find all useful resources.

  • Paolo Di Pasquale

    Thanks for this video, the new “rem” unit was well explained and I think I will probably try using it in the future.

  • Anonymous

    Hi TaoistTotty. Fixed. All listed above. Thanks and enjoy

  • Chris LaChance

    Thanks for making it clear & simple to understand how to use (or not use).

  • Anonymous

    Very clear Russ. Think I’ll be trying this in the future.

  • Haggle

    Thanks and enjoy

  • Brian

    I use rem units with a pixel fallback to help future-proof my new projects. I use SASS as a preprocessor and created a mixin that calculates rem sizes based on supplied pixel values and includes a default pixel fallback. Someday, I plan on switching the default pixel fallback off (as older browsers without rem support are phased out), then recompiling the CSS!

    • brothercake

      But if you do that, then you’ve lost the ability to resize text in older versions of IE.

      I think rem is a great concept, but I can see myself using it until all browsers in current use (not just the latest ones) support it. There’s no progressive enhancement with something like this.

      • Anonymous

        “I think rem is a great concept, but I can see myself using it until all browsers in current use (not just the latest ones) support it. There’s no progressive enhancement with something like this.”

        brothercake, just do as Brian said and provide a pixel fallback. Here’s an example:

        font-size: 14px;
        font-size: 1.4rem;

        • brothercake

          But if you do that, then you’ve lost the ability to resize text in older versions of IE.

          • Anonymous

            brothercake, it doesn’t have to be a pixel fallback. It could be an ems/percentage fallback or whatever you want.

          • brothercake

            Which would then re-introduce all the problems that rem avoided. It’s a vicious circle.

  • Brian

    By the way, the Sitepoint redesign looks great!
    Very clean and easy on the eyes, nice work!

  • bytemarc

    So if we use a pixel fall back, IE 6 through 8 won’t be able to increase the font size.
    Isn’t this the main reason we went to ems/percentages in the first place?
    If we are going to ignore IE 6-8 anyway, why not just use px and be done with it?

    • brothercake

      We’re not going to ignore them, that’s the whole point.

      That is the reason why em/percentage have been the preferred method of specifying fonts. And it’s still the case, and will remain the case (and the only accessible choice) for as long these versions are still in use.

  • yuda

    Great tute & links – thanks!

  • Brian

    It is not a vicious circle and it is progressive enhancement! Provide a non-rem unit fallback for crusty old browsers and rems for newer, capable browsers. Be sure to put the rem unit rules last as they will override the non-rem unit rules since they are last in the cascade.

    Here are the recent numbers we are fussing over:

    IE6 0.1 %
    IE7 0.7 %
    IE8 4.8 %

    What percentage of these need to resize fonts … I don’t know, but it is a small percentage. As always consult your own anaytics, rather than the above, but it is worth seeing world trends over time. For my projects, I am focusing on mobile first (with relative font units) while keeping accessibility in mind!

    • brothercake

      It doesn’t matter what the percentages are, accessibility issues transcend such qualifications. By their very nature, accessibility issues only affect small minorities, but for those they do affect, the problems are serious.

      In programming parlance we would refer to this as “low impact, high severity”.

      So you can’t use px for the fallback font-size, because then users of all those IE versions won’t be able to resize the text. But if you use em or % for the fallback, then you’ve still got to do all those micro adjustments to compensate for nested font-sizes. And if you’ve got to do that anyway, then you’ve gained nothing by using rem. There’s the vicious circle.

      It’s not a progressive enhancement because it’s not progressive, it’s a binary choice — either you can use it for everyone, or you can’t use it for anyone.

      Maybe when total usage drops below 1% (for all those older versions added together) then we can forget about them. But not today.

      (None of this is a criticism of what Russ is saying though. I look forward to the day when we can put this into practice, but I can’t let go of today’s concerns for the sake of tomorrow’s convenience.)

  • Ryan

    CSS preprocessors can help in the transition of using rems. I use a SASS mixin that provides both the pixel and rem units for the provided property…

    @include rem(padding, 20px);


    @include rem(padding, 2rem);

    Both of these produce the following CSS…

    padding: 20px;
    padding: 2rem;

    Here’s a link to the mixin.

  • Anonymous

    I too was going to mention a mixin but brothercake’s grievance seems to be with the final output, however it’s arrived at. brothercake can do what he wants. The project I am working on now uses rems with a pixel fallback but it could change. I have yet to find a 100% quintessentially perfect font-size solution but at the same time I don’t think “don’t use rems at all . . . or at least for quite some time” is the answer.

    On a slightly different topic I sometimes wonder if there’s a ghost/ricochet effect when it comes to browser stats where developers checking their sites on IE6 inflates the tracked usage of IE6 and maybe somebody is using Chrome Frame with IE6 but perhaps it still counts in usage stats as IE6 usage even though the user is getting a Chrome experience.

    • brothercake

      Absolutely — if you don’t think that the accessibility needs of people with older browsers is important, then yes, you can do what you want.

  • Anonymous

    “if you don’t think that the accessibility needs of people with older browsers is important”

    It should be clear by now that nobody is saying that and that, in fact, ways of still meeting that need have been presented.

    • brothercake

      If you’re advocating the use px as a fallback, then that this is exactly what you’re saying.

      The way of still meeting that is to use em or % as a fallback. But if you do that, then what was the point of using rem?

  • Anonymous

    Please feel free to not use rems if you don’t want to. We’re provided multiple font-size units (and there’s at least six I can think of that haven’t been discussed in this post/thread) and there’s different approaches that can be taken. Some choose a method that looks to the future while feeding the past even if it’s not a 100% perfect approach.

    • brothercake

      Yeah I totally understand that, I’m just being practical.

      If you have to provide a fallback that’s exactly the same as what you were doing anyway, AND you’re defining rem fonts as well, what was the point? Who benefits? All you’ve done is increased the size of your stylesheets, and created more work for yourself, without gaining any benefit at all.

      I’m all for looking to the future, but embrace new ideas because they’re better, not just for the sake of it.

  • Anonymous

    Your issue here seems to be more with fallbacks in general.

  • Anonymous

    Do you have some more examples of em/rem benefits over pixels? Want to see some real-life examples, that will show the pixels problem.

    • Brian

      There are two main benefits of using em/rem units over pixels units for font-sizes. The first reason, is maintaining legibility with the vast devices with different viewports and pixel densities. Different devices have different pixel densities, thus pixel based fonts may appear too large or too small on certain devices. Related to this is em/rem units cascade and this may be useful for media queries on responsive sites. The second reason is accessibility. As brothercake mentioned, pre IE9 users, are not able to scale (zoom-in presumably) pixel units. Using pixels takes control away from the user (by preventing changes to font sizes).

      An interesting fact about the CSS pixel unit is they do not actually have anything to do with screen pixels, they are units of measurement based on the devices intended viewing distance!

      • Brian

        Actually, there is misinformation out there about the pixel unit and screen pixels, please disregard my “interesting fact” … the point to take home is em/rem units are mobile friendly and accessible.

  • brothercake

    My issue is not with fallbacks, my issue is with the use of pixels for font-sizing. That’s all.

    It’s a well documented issue — versions of IE earlier than IE9 can’t resize fonts that are defined in pixels.

  • Anonymous

    At this point I’m pretty sure there’s a group of people standing behind a one-way mirror and laughing at me for continuing to answer you when you are acting a lot like a troll.

    “It’s a well documented issue — versions of IE earlier than IE9 can’t resize fonts that are defined in pixels.”

    You see: nobody’s telling you you have to use pixels. It was suggested as something you can fall back to if you wanted but also pointed out that you can fall back to other types of units. Or not provide a fallback at all. Or continue using em’s/% as the fallback. If you don’t want to add a few extra characters to your CSS THEN DON’T DO IT. But you keep acting like somebody’s forcing you to use pixels.

    The mixins were mentioned because they help you deal with specifying a fallback in one spot, that is then propagated to more than one spot upon compilation, and then if YOU get to the point (assuming you’re using the mixin at all) that YOU feel YOU don’t need the fallback anymore then you can delete that one little line in the LESS/SCSS/SASS (or whatever) that creates the fallback. Problem solved. Or you can leave it in and live eternally with the weight of a couple extra characters in your CSS.

    I think the issue here is not rem’s or pixels how much we should act like IE9- is our slave master. This type of discussion goes on in many forums, threads, posts, etc., where some post author has pointed out a new CSS feature (or a neglected but newly re-discovered feature) and a bunch of people go, “That’s awesome!” And some say, “That’s nice. I’ll set it up with a fallback.” And some say, “Oh, no, we can’t use that in the slightest degree until IE9- drops off usage stats. Or at least below 1%. Or .1%.” The beauty of CSS is that you’re not locked into any one method. Use whatever method you want. If you see somebody using rem’s on a site and because of the way they’ve implemented it their site is behaving horribly in IE9- then contact them about it. Including any of my sites.

    • Anonymous

      I don’t think anyone’s laughing at you for anything, and I’m quite sure brothercake is not a troll. I agree with him that, while older versions of IE will go away over time, the issue of accessibility – which is absolute – won’t go away until they do. Where I differ in opinion to brothercake is that this makes the use of rem units untenable now. Yes, using ems or % negates the benefit of using rems, but only for that small (and falling) number of browsers that don’t support rems. That makes resizing accessible for the older browsers while newer browsers get the full benefit of rems. It’s not perfect, and won’t be until all browsers support rems but the em/% fallback is an acceptable (and accessible) option until that happens. The real risk is that coders do use the pixel fallback, or no fallback, when using rems because to use ems/%s requires extra work. They then sacrifice accessibility. That is unacceptable, no matter what the numbers of users affected are.

      • brothercake

        That’s an interesting point you make, and I did consider it in those terms — if we can provide something better for modern browsers, then it’s worth doing, as long as we have an acceptable solution for older ones.

        But the thing is — there are no benefits for modern browsers — as far as browsers and users are concerned, it’s makes no difference at all.

        The benefits of rem over em are purely our convenience, convenience which is lost by the need to use an em fallback. Or is there another benefit of rem apart from solving the compounding problem?

        • Brian

          Not that I am aware of … some people still advocate the use of em when styling type-related properties, such as the padding around the text on a button. If a user resizes the font, then the padding maintains its proportion. Of course this would work for the rem too. Actually, one benefit that comes to mind is when styling for a CMS where you cannot necessarily predict how the markup will be nested in the future. In this scenario, you will not be able to know the parent and thus may run into compounding issues with the em unit. Web design is already difficult enough, I prefer the relative simplicity of the rem unit instead of tracking a shifting baseline. Again, CSS preprocessors make most of this easier.

          Note: I imagine you will feel the accessibility issue is kinda skirted under ‘progressive accessibility’

          In your experience, do you know if pre-IE9 users with zoom needs for accessibility are typically able to user a different browser (with rem support) or screen reader?

          • brothercake

            Well this is the point isn’t it — rems are a fantastic unit, but they don’t anything for users compared with ems, they’re simply “ems which are easier to use”. But that ease of use is entirely negated by the need to define a fallback.

            Though not if you use a pre-processor, because that can shield you from the pain. It also shields you from the reality of how much extra output code it takes to make it work. When developers are confronted with the reality of such decisions, they tend to make more conservative choices, which is why hand-written stylesheets are always much smaller than pre-processed ones.

            Are pre-IE9 users able to use a different browser? Presumably not, but there’s no way of knowing. And because there’s no way of knowing, we have to err on the side of caution. Maybe some users could make that choice, but unless we can assert that ALL users can make that choice, then it becomes irrelevant whether they can or not.

            In other words, if 99% of IE9 users are making a choice, but 1% have no choice, then that’s the same as 100% having no choice.

  • brothercake

    There’s no need to be like that. I was simply expressing a point relating to accessibility in older browsers. If people want to ignore that, there’s nothing more I can do.

  • Anonymous

    “If people want to ignore that, there’s nothing more I can do.” Fortunately I never said to ignore it. Never even hinted at it. That’s what was frustrating: that I was telling how to still cater to older browsers but I was being interpreted as saying to ignore them.

    • brothercake

      I never said “you”, and I know you understand the difference between px and em fallback. But you and me aren’t the only ones in this discussion :-) I continued to make the same point for as long as anyone (not necessarily you) disputed the truth or implications of it.

  • Brian

    I agree, rems do not do anything for the user compared to rems. Except if the user is the client or the content system manager who may nest markup that triggers unexpected compounding if em units are used (and therefore undesired styling). But for me, the developer, the rem units are much easier to use. It also important to develop for developers who may inherit code maintenance or my future self. So it is not just about the users.

    I disagree, with your points about preprocessing. I understand “the reality of the CSS output” because I write and test the mixins and I understand how much vanilla CSS the preprocessor creates because I review it!

    Lastly, I agree that because there are unknowns, we should take a conservative approach for accessibility.

  • Web Axe

    Great tutorial, thanks! I’ve posted to FB & Twitter…

  • Brian

    Great video – thank you Russ

  • Great explanation of Rems. Thanks!

  • Great explanation, I haven’t used rem a lot yet but its something we hope to start implementing in future projects.

Get the latest in Front-end, once a week, for free.