On ems and rems

Posted by Scott on 07/19/2012

Topics:

In our most recent post, How we learned to leave default font-size alone and embrace the em, we noted a few reasons why we’ve recently stopped setting a body font-size in our CSS. Several readers commented that they now prefer using rem units instead of ems, and as a result, they don’t run into the issues we observed. We agree that rems are fantastic, but thought we should note that rems and ems serve different purposes and need not be mutually exclusive; both can be very useful in the same CSS layout, depending on what you’re trying to do!

Perhaps the most attractive aspect of rems is that they are always relative to the root element's (<html>) font-size regardless of the context in which they are used in an HTML document. In other words, 1rem always equals the same thing (by default, usually about 16px), and that consistency does make rems a lot easier to work with than em units, which are relative to the font-size of the parent of the element you're styling. (If you're new to rem units, we'd recommend checking out Jonathan Snook's great article on the topic.)

But that same benefit of rems also means that they can be less helpful when designing proportional whitespace, such as padding and margins that surround the typography in a fluid layout. This is where em units shine. Take for example, a block of content that contains a heading and a paragraph. The amount of spacing that feels comfortable between the heading and the paragraph (and the space between them and adjacent pieces of content) will often change depending on the size of the text. Using em units for the margins and padding in cases like this mean the spacing will automatically adjust in proportion to the font-size, regardless of what it may be. If used in this same situation, rems would require manual adjustment. This jsbin example attempts to demonstrate this difference simply, but it becomes more obvious when designing complex, gridded layouts.

ems come with another benefit: when components are set entirely in ems, they scale in unison depending on the font-size of their containing element. This can be very powerful, particularly when reusing the same components in different parts of a layout, where it might make sense for a component to be larger or smaller as a whole.

Meanwhile, rems have another potential downside. If you care to support Internet Explorer 8 and older, or any version of Opera Mini, you’ll need to provide a fallback px- or em-based number alongside every use of rems, which makes our jobs a little harder, while increasing the code weight that we’re delivering to the user (however minimally).

To sum things up, rems are a great emerging technology. Knowing when it’s a good idea to use them, and when it’s not, is something we’re still considering ourselves.

Book cover: Designing with Progressive Enhancement

Enjoy our blog? You'll love our book.

For info and ordering: Visit the book site

Comments

You should also mention something very important…

http://codepen.io/grayghostvisuals/full/AFjDK

@media screen and (max-width: 36rem) {
/* Hi I don’t work */
}

@media screen and (max-width: 36em) {
/* Hi I work */
}

Comment by Gray Ghost Visuals on 07/20  at  05:35 PM

I prefer to use REMs for font-sizing and EMs for layout adjustments like margins, paddings, etc. Adding a pixel fallback when sizing fonts with REMs is a small price to pay for consistency with font sizes and if you are using a css-preprocessor you can use pixels for font-sizes and have the correct rem value generated for you.

Comment by Brett Jankord on 07/20  at  05:47 PM

@GrayGhostVisuals: oh hey, great point. Thanks for chiming in.

Comment by Scott (Filament) on 07/20  at  05:48 PM

@GrayGhostVisuals: Interestingly, it looks like this might be a WebKit bug. Per the media query spec, rem should work fine there. I just gave your test page a shot in Firefox (14) and Opera (12) and things behaved as expected.

Even more confusing is that the spec says rems should have the exact same behavior as ems, so I’m not sure why WebKit is doin’ what it’s doin’. Looks like there’s an unconfirmed bug in the WebKit tracker already.

Comment by Mat Marquis on 07/20  at  06:01 PM

@Scott
Love chiming in. Love Filament Group : ) Chirp, Chirp

Comment by Gray Ghost Visuals on 07/20  at  06:02 PM

@Machine Guns Marquis

Oh Man! Nice Catch Fisherman man man
Boo -Webkit

Comment by Gray Ghost Visuals on 07/20  at  06:11 PM

So in general using rem (px) for font-size and em for dimensions/whitespace would be a nice way to go?

Comment by Thomas "Thasmo" Deinhamer on 07/20  at  08:33 PM

“[rems] are always relative to the browser’s default font-size regardless of the context in which they are used in an HTML document\”

This is definitely not true. Rems are not relative to the browser’s default font-size, they are relative to the root element, which, in an HTML document, is <html>. You can easily change the value of a rem by something like:

html { font-size: 20px; }

Comment by Philip Walton on 07/21  at  01:31 AM

@Philip: fair point; “always” sounds rather absolute.

Comment by Scott (Filament) on 07/21  at  05:36 AM

@Philip: I updated the post. Thanks for the note.

Comment by Scott (Filament) on 07/21  at  05:46 AM

Commenting is closed for this post.

Book cover: Designing with Progressive Enhancement

Enjoy our blog? You'll love our book.

For info and ordering: Visit the book site