The Rise of REM

As web designers and web developers we live in a world of pixels, such is the state of display technology. We also like to make things easier to work with and in a world of small and large viewports the pixel had to go. When we consider that the primary mode of the web is text it makes sense to size the internets around font-size. Some love the clarity of ‘px’ and some like the relative sizing of the ‘em’. Others must have thought it a bright idea to give us both so we get the ‘rem’. Problem solved. (*sigh*)

First the good and let me be clear on this: The ‘rem’ unit will save a lot of people a lot of headaches when dealing with poorly coded CSS because it ignores the cascade. For that reason alone it’s an interesting option to have. In combination with the ’em’ it can work when used as a universal pattern.


#widget {
    font-size: 0.9rem; /* reset the cascade */
#widget header {
    font-size: 1.2em;
#widget section {
    font-size: 1em;
#widget footer {
    font-size: 0.9em;

The downside is that when you reduce the font size on a block of elements by setting, for example, the size of the #widget parent aside nothing will change because rem, acts like a reset. Using ‘px’ would have the same unfortunate behaviour but at least it’s easier to guess what’s it’s going to do. In any case such resetting behaviour will likely make sites more work to style, especially responsive ones. Remember that more code is bad and less code, to do the same thing, is good.

Long ago I learned the hard way to never give common text elements like paragraphs and lists a font-size, never, ever. My example above obviously reflects that. Manage the context and set your “new” typography on the nested context. Let the cascade do the work for you. The “rem” addition is an admission that many don’t like the cascade, they often don’t like CSS’s declarative nature either—but that’s a whole other post.

White space

One of the long standing issues with CSS is it’s lack of layout control. It forces us to work around the cascade when it comes to adding margins and padding to layout containers.

White space is always directly related to its surroundings. So, an interline is relative to the text and using a ‘rem’ would make no sense at all. Body text is usually related to the page and in CSS terms we would refer to the ‘root’ so using ‘rem’ for its margins or padding does makes sense. When you have nested containers that also require white space that’s related to the page itself then using ‘rem’ for margins or padding is your best bet, especially in the horizontal space.

CSS for a three column panelled layout:

html {
    /* Based on the browser default of 16px: 62.5% = 1em = 10px */
    font-size: 62.5%; 
body {
    margin: 0;
    font-size: 1.4em; 
    padding: 2rem;
.promo {
    padding: 1em;
    box-sizing: border-box;
#promotions {
    font-size: 1.2em;
#promotions .promo {
    float: left;
    margin-left: 2rem;
    width: calc( 100% / 3 - 1.3333rem );
#promotions .promo:first-child {
    margin-left: 0;

Example on codepen

What’s really obvious and frustrating is that flex-box and grid-layout are still not ready to be used in the wild.

Note that setting the font-size on body doesn’t effect ‘rem’ because body isn’t the root element. If your body has a font-size other than 1em or 100% then switch to ‘rem’ units for the padding. Adding font-size on both html and body can be an effective combination with ‘rem’ but also very confusing.

Your job requires discipline, deal with it.

Adding features to the cascade will inevitably make it a little more brittle because you can’t force others not to nest rem and or ‘px’ units inside ems. Sticking to a single unit for everything isn’t always a workable solution, but how do you avoid a free for all? The only way to avoid a project descending into CSS anarchy is to bring out your inner font-nazi or variation thereof. There, I’ve invoked Godwin’s law before the first comment.

Step one: Explain yourself.

Write or agree on a primer that outlines the rules of the game for a particular project or team. Sadly, tools to check for poor adherence to cascading conventions are not available. So, remember to assert good CSS authoring practices. Have others frequently review your work and never assume your code is not affected by the cascade. If you work in a team then have areas of responsibility assigned to individual members. These would at least be something like; Layout, typography, forms, navigation, colour, media, widgets, UI libraries, mixins, accessibility and compatibility.

If the “rem” unit tickles your fancy then you may need the rest of the team to buy in to your flavour of unit. It could easily devolve into a tab versus spaces discussion. If you work in your lonesome then use the different styling areas to asses if “rem” won’t cause to much disruption. Mixing in third party libraries could easily throw a spanner in the works.

Almost ready

For now I personally would avoid using “rem” units on customer projects as it has a reset like quality when nested whilst also being a relative value. Debugging a stylesheet isn’t my favourite hobby and the “rem” isn’t going to make that any easier. This problem will hopefully become more manageable as authoring conventions start to emerge. I do suggest playing around with the ‘rem’ unit now, because it’s most certainly going to become part of the CSS landscape whether you like it or not.