CSS units have been the subject of several articles here on SitePoint (such as A Look at Length Units in CSS, The New CSS3 Relative Font Sizing Units, and The Power of em Units in CSS).

Today we increase the count by having an in-depth look at rem units, which have excellent browser support and a polyfill if you need support for old IE.

What Are rem Units?

You might have encountered the term “R.E.M.” before while listening to the radio or your music player. Unlike their musical counterparts, named for the “Rapid Eye Movement” during deep sleep, in CSS rem stands for “root em”. They won’t make you lose your religion nor believe in a man on the moon. What they can do is help you achieve a harmonious and balanced design.

According to the W3C spec the definition for one rem unit is:

Equal to the computed value of font-size on the root element. When specified on the font-size property of the root element, the rem units refer to the property’s initial value.

This means that 1rem equals the font size of the html element (which for most browsers has a default value of 16px).

Rem Units vs. Em Units

The main problem with em units is that they are relative to the font size of their own element. As such they can cascade and cause unexpected results. Let’s consider the following example, where we want lists to have a font size of 12px, in the case where the root font size is the default 16px:

html {  font-size: 100%;}ul {  font-size: 0.75em;}

If we have a list nested inside another list, the font size of the inner list will be 75% of the size of its parent (in this case9px). We can still overcome this problem by using something along these lines:

ul ul {  font-size: 1em;}

This does the trick, however we still have to pay a lot of attention to situations where nesting gets even deeper.

With rem units, things are a simpler:

html {  font-size: 100%;}ul {  font-size: 0.75rem;}

As all the sizes are referenced from the root font size, there is no more need to cover the nesting cases in separate declarations.

Font Sizing with Rem Units

One of the pioneers of using rem units for font sizing is Jonathan Snook with his Font sizing with REM article, back in May, 2011. Like many other CSS developers, he had to face the problems that em units bring in complex layouts.

At that time, older versions of IE still had large market shares and they were unable to zoom text that was sized with pixels. However, as we saw earlier, it is very easy to lose track of nesting and get unexpected results with em units.

The main issue with using rem for font sizing is that the values are somewhat difficult to use. Let’s see an example of some common font sizes expressed in rem units, assuming, of course, that the base size is 16px:

• 10px = 0.625rem
• 12px = 0.75rem
• 14px = 0.875rem
• 16px = 1rem (base)
• 18px = 1.125rem
• 20px = 1.25rem
• 24px = 1.5rem
• 30px = 1.875rem
• 32px = 2rem

As we can see, these values are not very convenient for making calculations. For this reason, Snook used a trick called “62.5%“. It was not a new discovery, by any means, as it was already used with em units:

body { font-size:62.5%; }  /* =10px */h1   { font-size: 2.4em; } /* =24px */p    { font-size: 1.4em; } /* =14px */li   { font-size: 1.4em; } /* =14px? */

As rem units are relative to the root element, Snook’s variant of the solution becomes:

html { font-size: 62.5%; }  /* =10px */body { font-size: 1.4rem; } /* =14px */h1   { font-size: 2.4rem; } /* =24px */

One also had to take into account the other browsers that didn’t support rem. Thus the code from above would have actually been written this way:

html {    font-size: 62.5%;}body {    font-size: 14px;    font-size: 1.4rem;}h1 {    font-size: 24px;    font-size: 2.4rem;}

While this solution seems to be close to the status of a “golden rule”, there are people who advise against using it blindingly. Harry Roberts writes his own take on the use of rem units. In his opinion, while the 62.5% solution makes calculation easier (as the font sizes in px are 10 times their rem values), it ends up forcing developers to explicitly rewrite all the font sizes in their website.

A third view comes from Chris Coyier of CSS-Tricks. His solution makes use of all three units we encountered so far. He keeps the root size defined in px, modules defined with rem units, and elements inside modules sized with em. This approach makes easier to manipulate global size, which scales the type in the modules, while the module content is scaled based on the module font size itself. Louis Lazaris discussed that latter concept in The Power of em Units in CSS.

In the example below you can see how Chris’s approach would look:

As you can see, there is no “silver bullet” solution. The combinations possible are limited only by the imagination of the developers.

Using rems with Media Query Breakpoints

The use of em or rem units inside media queries is closely related to the notion of “optimal line length” and how it influences the reading experience. In September 2014, Smashing Magazine published a comprehensive study on web typography called Size Matters: Balancing Line Length And Font Size In Responsive Web Design. Among many other interesting things, the articles gives an estimate for optimal line length: between 45 and 75-85 characters (including spaces and punctuation), with 65 the “ideal” target value.

Using a rough estimate of 1rem = 1character, we can control the flow of text for a single column of content, in a mobile-first approach:

.container {  width: 100%;}@media (min-width: 85rem) {  .container {    width: 65rem;  }}

There is, however, one interesting detail about rem and em units when used as units for media queries: they always keep the same value of 1rem = 1em = browser-set font size. The reason for this behavior is explained in the media query spec(emphasis added):

Relative units in media queries are based on the initial value, which means that units are never based on results of declarations. For example, in HTML, the em unit is relative to the initial value of font-size, defined by the user agent or the user’s preferences, not any styling on the page.

Let’s see a quick example of this behavior:

View Media Query Demo on CodePen

First, in our HTML, we have a <span> element where we will write the width of the viewport:

Document width: <span></span>px

Next we have two media queries, one with rem units and the other with em units (this uses Sass for simplicity):

html {  font-size: 62.5%; /* 62.5% of 16px = 10px */  @media (min-width: 20rem) {    /* 20*16px = 320px */    background-color: lemonchiffon;    font-size: 200%;    /* 200% of 16px = 32px */  }  @media (min-width: 30em) {    /* 30*16px = 480px */    background-color: lightblue;    font-size: 300%; /* 300% of 16px = 30px */  }}

Finally, we use a bit of jQuery to display the viewport width on the page, updating the value when the window size changes:

$(‘span‘).text($(window).width());$(window).on(‘resize‘, function(e) {  $(‘span‘).text($(window).width());});

We begin with the 62.5% trick to show that the modified root font size does not have any effect on the values used for the media queries. As we change the width of the browser window we can see that the first media query kicks in at 320px (20 × 16px) while the second one becomes active at 480px (30 × 16px). None of the font-size changes we declared had any effect on the breakpoints. The only way to change the media query breakpoint values is to modify the default font size in the browser settings.

For this reason it doesn’t really matter if we use em or rem units for media query breakpoints. As a matter of fact, bothFoundation v5 and the newly announced Bootstrap v4 alpha use em units for their media queries.

Using rem Units for Scaling Documents

A third use we can find for rem units is to build scalable components. By expressing widths, margins, and padding in rem units, it becomes possible to create an interface that grows or shrinks in tune with the root font size. Let’s see how this thing works using a couple of examples.

Using rem Units for Scaling Documents Demo #1

In this first example, we change the root font size using media queries. Just like in the previous section, the purpose is to customize the reading experience for the device used. As element padding values and margins are expressed using rem, the entire component scales with the device size.

Let’s see another:

In the second example we do the same alteration using JavaScript. This time the user has control over the size of the interface, adjusting it to fit his needs. Add a way to store these custom values (using either a database, cookies or local storage) and you have the base of a personalization system based on user preferences.

Conclusion

We end here our encounter with CSS rem units. It is obvious that there are many advantages in using these units in our code, like responsiveness, scalability, improved reading experience, and greater flexibility in defining components. Rem units not a universal silver bullet solution but, with careful deployment, they can solve many problems that have irked developers for years. It’s up to each one of us to unlock the full potential of rems. Start your editors, experiment and share your results with the rest of us.

It’s not The End of the World as We Know It, rather it’s yet another path on the journey that makes front-end developers “Shiny Happy People“.