How we learned to leave default font-size alone and embrace the em

Posted by Scott, Mat, Zach, and Patty on 07/18/2012

Building with em units in CSS brings benefits in flexibility to users and developers alike, but working with ems can be tedious for a number of reasons. Most famously, the value of 1em only vaguely correlates to pixel-based design; the inconvenience of translating fixed design comps into flexible CSS units has long driven web designers to declare a global font-size to make that math a bit easier to manage. But using contemporary responsive design principles is convincing us to leave global font-size alone and embrace the standard em.

Perhaps the most popular global font-size workaround was introduced in Richard Rutter's brilliant 2004 article, "How to size text using ems," which revealed that by setting a body font-size of 62.5%, we change the default value of 1em to equal 10 pixels. This of course makes the conversion of pixels to ems dramatically easier. Ever since that article was released, we at Filament Group would typically start our CSS files with that rule, and happily carry on in our developer-convenient way.

But in the recent past, as we began building Responsive layouts—particularly layouts that use flexible em-based media query breakpoints—we've encountered several reasons that the practice of setting the body font-size is no longer such a good idea in our own work. We've observed that others have seemingly come to this realization as well, but hadn't seen anyone document why they made the change, so here are the reasons we've found:

  • The value of 1em, when used in a CSS3 Media Query such as @media (min-width: 20em), is unaffected by the font-size of the body element in most browsers. This means that if we change the font-size of the body to something other than 100%, we will need to calculate em values differently when they're used in a media query than in a CSS property value. This creates inconsistency across a CSS file that is difficult to maintain and document. (We recall that Opera Mobile or Mini actually behaved differently in this aspect, compounding the issue further, but we couldn't reproduce in the latest versions of the browsers.)
  • A default font-size of 10px is illegibly small for text, so if we use a 62.5% base font-size, we have to specifically set the font-size of every element that appears on our site to make it readable. Alternatively, if we leave the body font-size at 100%, we can allow elements to display in their natural size determined by the browser's default stylesheet. This makes for lighter CSS and more flexibility in the markup we choose to use.
  • Lastly, as we move into the browser earlier and earlier in our design processes, we're finding that the very idea of an em value relating to pixels is becoming less relevant. Our design decisions are now more commonly informed by the context in which a component lives in the page, and how it adapts fluidly and proportionally within that environment, regardless of its pixel-based scale.

So for those reasons, we're now tending to leave the body font-size alone, and we'd recommend other developers do the same.

Observant readers may notice that, ironically, at the time of writing this very website is still built using a body font-size of 62.5%. We're in the process of redesigning this site, and while we haven't gotten around to changing that part yet, the difficulty in creating our new em-based responsive layout with that default font-size in play was enough to prompt us to write this post!

Thoughts? We'd love to hear your ideas below.



Do you still need to specifically declare the body font-size at 100% or is omitting it completely enough to let the browsers default size it without problem?

Comment by Dan on 07/18  at  06:15 PM

Hey Dan, you shouldn’t need to declare anything in most cases, but if you’re writing shorthand font CSS, you might need to.  For example, “font: normal 100%/1.5 sans-serif; “

Comment by Scott (Filament) on 07/18  at  06:17 PM

I’ve been leaving the default font size alone and sizing all measurable properties with rems. I use a Sass mixin that calculates rem values based off of pixel dimensions that get passed to it, and the mixin can alternately output a pixel-based fallback for browsers that don’t support the rem unit (i.e. older IE). This method has been working very well for me over the past year or so, and I’ll most likely continue to tweak my rem process as time goes on. Ems are pretty swell, too, though!

Comment by Ray Brown on 07/18  at  06:27 PM

So you’re saying if I declared my css shorthand for font size on the body element and recalc it in a media query then the values of other children would have to be reassessed for their em equivalent?

How in the world do we determine a value of the em if their is no parent to base it off of?

Comment by gray ghost visuals on 07/18  at  06:43 PM

@Gray Ghost Visuals: Hmm. Well, not exactly…

I just mean that the value of 1em within the media query itself (the @media (min-width: 25em) part), and the body of all media queries (within their {..} braces) will be different from each other if you change the body’s font size.

Not setting the body’s font size isn’t a major change. It just means the default value of 1em is relative to the browser’s default font-size (usually 16px), so you calculate off of that. The value of 1em will still vary depending on the nesting context of an element; the value of 1em matches the inherited font-size of its parent.

Comment by Scott (Filament) on 07/18  at  07:15 PM

Absolutely Scott! On a recent project (a very high profile site in Portugal), ever since we started laying out type, EMs just felt right. We did, however, stopped thinking in specific pixels right off the bat so Rich’s magic number to make 1em match more or less 10px was never a big concern. We let the content & context lead the way into our proportion adjustments. Exactly what you said above. ;)

Funny thing… I just went back and looked through the stylesheets of our recently released website and whaddya know? We’re zooming out on the HTML element (~60%) and then zooming in on the BODY element (1.5em). Hahaha. Silly but probably caused by the old habit of zooming out the default size. ;) I bet browsers are shrugging to themselves and thinking “would you make up your goddamn mind?!”

These are remnants of a few tweaks we had to do after some initial user-feedback. But now that we’re done, we need to make this a bit more sane. Thanks for writing this.

Comment by André Luís on 07/18  at  07:19 PM

“The value of 1em, when used in a CSS3 Media Query such as @media (min-width: 20em), is unaffected by the font-size of the body element in most browsers”

Not had a chance to test, but my immediate thought: does this also hold true if you’re changing the overall font-size for html rather than body?

Comment by Patrick H. Lauke on 07/18  at  09:12 PM

@Patrick: Good question. The post is focused on the body font-size because that’s what we assume to be most common. I’m not sure whether browsers respond differently to changes in the html element’s font-size (though I do remember testing it at one point just to see… maybe that’s where that Opera note came from...?). Either way, I think the second bullet above would hold as a good reason why setting the html element’s font-size wouldn’t be particularly helpful in our workflow either.  Do you agree?

Comment by Scott (Filament) on 07/18  at  10:46 PM

So far in my tests, the EMs media-queries are also unaffected as well if you set font-size on the html element.

I still think it’s handy if you want to make global adjustments on your type, but set it like you do on any other element… by need and not by default. If you need to A/B test something with a different baseline font-size, go for it. No harm done. But messing with it by default/habit induces other behavior you don’t want. Or the illusion of precision, which we don’t have anymore. ; ) User preferences ftw!

Comment by André Luís on 07/19  at  04:04 AM

Recently I’ve been using a different approach. I use the 62.5% on the <html> & use remS instead of emS with a px fallback. then on the <body> I can use 1.4rem for example.

The thing about remS that it always refer to the root element (which is always the <html>) so anywhere in my stylesheet I want a 30px header, I only need to write 3rem without worrying about em calculations. I use SASS so I have a mixin to output both the rem value & the px fallback value.

Comment by Gabri on 07/19  at  04:05 AM

“I think the second bullet above would hold as a good reason why setting the html element’s font-size wouldn’t be particularly helpful in our workflow either.  Do you agree?”

Sure, 10px is a bit too tiny for default text. But I was thinking more generally that I tend to tweak the overall size to something like 0.8em / 80% - not for ease of calculating em/px things, but rather because even today, the default 1em size in all browsers feels strangely big and chunky. Less of an issue now that we all have 30” screens in front of us, but on smaller displays (laptops/netbooks) the default always felt clownishly large and amateurish. That, more than ease of calculation, is the reason why a lot of people tweaked font sizes, IMHO.

Comment by Patrick H. Lauke on 07/19  at  05:09 AM

Chalk it up to naivety, but why are you using ems in the media query? What is the benefit? I always associated ems with font size only so applying that to viewport width confuses me.

Comment by Ian Moffitt on 07/19  at  07:18 AM

In 10 years of web development, the only time I’ve had negative feedback from a client regarding font sizes/layout etc was when I chose to use EMs and the 62.5% body reset approach.  I’m seriously not trolling here, but it seems that EMs make life so much harder than just using px values.  In a time when every popular browser/device has in-built mechanisms for sizing content natively, then why would you choose EMs?  Is it to support IE6 users who’s text doesn’t scale with the native zoom?  Genuinely interested, and I repeat, this is not a troll - I realise most readers here will be firmly in the EMs camp, I’m just interested to know why.

Comment by Dan on 07/19  at  07:41 AM

I never liked that 62.5% rule. It’s kind of an admission that you can’t do Maths. I mean, really, is it too taxing to divide by 16 instead of dividing by 10?

I think CSS media queries should really have required the use of the ‘rem’ unit. That would have made it clear where the font-size is being queried. I use the ‘rem’ unit pretty exclusively these days (with ‘px’ backup for IE), except when I know I want blocks to scale with respect to their context.

Comment by Stephen Band on 07/19  at  07:57 AM

@Ian: Em-based media queries tie your breakpoints to your content and layout, rather than the viewport dimensions. For example, if you a user bumps up their font-size, breakpoints written in ems will adapt along with the size, changing to whatever breakpoint makes sense for that particular proportion. Currently, Opera browser handles this best, on the fly, while a browser like Chrome doesn’t adapt the layout unless you refresh. For more reasons, I’d recommend checking out the post from Cloud Four, linked above, and here:

@Dan: ems are all about designing proportionally, rather than to particular pixel dimensions. There are many benefits to using them. The IE scaling issue may have caused people to start using ems originally, but their value goes far beyond that workaround. They work more naturally alongside fluid, percentage-based units and afford a level of flexibility that’s not possible in fixed pixel units.

@Everyone: rem units are great too, browser support issues aside. No argument there. :)

Comment by Scott (Filament) on 07/19  at  08:12 AM

I’m wondering if using rems would have the same problem in media queries if you changed the html elements initial font size.

Also wondering how the various user settings play into this as well.  Does a user setting their default font size/a custom stylesheet also affect how ems/rems get evaluated in media queries?

I’m thinking more digging might be necessary.  Especially if a user defined stylesheet or font size behaves as setting a font size on the body/html in regards to ems in media queries.

One final thought: does this pattern hold true if you set the font size on the html element instead of the body element?

Comment by Art Lawry on 07/19  at  08:20 AM

1. As far as I know, the value of 1rem is not affected by body font-size, so in that case rems would not have this same issue. The issue here is that EMs within media query statements actually behave like REMs, but otherwise do not.

2. I’d assume changing the browser’s default font-size (via preferences) will change the value of 1rem universally. Not sure if user stylesheets would be any different than author stylesheets.

Let us know what you find!

3. See Patrick’s comments (and my replies) above.

Comment by Scott (Filament) on 07/19  at  08:33 AM

Agree with this approach - I’ve been doing this since 2001 :)

Comment by Steve Lorek on 07/19  at  08:44 AM

When starting out on a new site, I’ll set my font-size to 100% on the HTML element and then user rems with a pixel fallback. As Ray Brown mentioned, you can use a CSS pre-processor to generate you rem value based on the pixel font size you set if you dont feel like doing the maths.

Kyle Schaeffer has a good article on sizing text with various units. I started setting font-size to 100% on my html element based on his article - Check out the section, EM vs Percent.

Comment by Brett Jankord on 07/19  at  09:01 AM

Why ems? Why not a percentage? Using ems seems like moving from one unit based measure (pt or pixel) to another unit based measure.

Comment by Melriks Design on 07/19  at  09:07 AM

Glad you guys are documenting good reasons not to change the default value. I stripped it out of my reset styles a couple years back, but only because I realized I was sizing text up up into the 16px base range more often than not anyway. Once I was working in the mobile arena more heavily, I realized that the fan favorite of 12px paragraph sizes was too difficult for my aging eyes to read comfortably!

So, my reasons for making the switch were (in order of priority):

1. Self centered design desires
2. Too lazy to math my way back up from 10px to 16px and beyond.


Comment by Bridget Stewart on 07/19  at  10:09 AM

Here’s what I’ve verified:

1. Using rems in media query breakpoints has the same problem of ems.
2. This issue exists whether setting font size on the body or the html element, even for rems.
3. Changing the browser font size via font-zoom DOES affect the value of ems and rems in media queries. Basically, this means you never know the value of the em or rem used in breakpoint calculations.
4. I didn’t try a custom stylesheet with body or html font size set as number 3 was pretty damning.

I have to agree that 100% font size on the body or html element is the way to go to avoid problems with em/rem-based breakpoints. Thanks for sharing your findings!

Comment by Art Lawry on 07/19  at  10:45 AM

@Art number 3 is not ‘pretty damning’ - it’s the whole reason for using ems in the first place: you never know what the font size is, but you can make everything relative to it so that your design scales.

Comment by Stephen Band on 07/19  at  11:56 AM

Not sure I fully understand your post, but in each media query I import a typography stylesheet which contains LESS math which relatively resizes typography using a @baseFontSize variable that is set to 1em by default. This variable can be changed in the mq and all the math recalculated based on “mq context”. My grid system works in a similar manner.
As a side question, does your layout ever use % or px? Or are all the structure elements based off ems, like your typography? Perhaps I should experiment with a LESS em unit grid as there are issues when a user significantly increases their browser fonts using % or px grid. But if the grid and font use the same units then perhaps the issues are resolved? Twitter Bootstrap and Zurb Foundation seem to be designed around px fonts.

Comment by Brian on 07/19  at  12:35 PM

@Stephen - I love me some ems & rems.  “Pretty damning” was in reference to the idea that some things don’t affect media query em sizing (setting font-size on the body or html element) while some things do (changing the font size of the browser), supporting the original argument to size html/body with font-size: 100%. Apologies if my phrasing confused you. I’m a better coder than communicator.

Comment by Art Lawry on 07/19  at  01:06 PM

Do you have an example of a site using this methodology?

Comment by AnnieMac on 07/19  at  08:58 PM

Great article and I am pleased to see more well argued points for ems. For responsive web design, using em is a no brainer. The relative nature of the em allows an incredible amount of flexibility when needing to scale different portions of a site for different contexts, something that rem can’t do. This contextual flexibility is easier compared to percents than pixels, in fact percent based scaling is almost identical to em based scaling of font size.

That said, I think demonizing the pixel is going too far. According to the w3c it is a relative unit based on viewing distance. While it is not relative to the units around it, the pixel is a solid unit of measurement for sizing elements that need to remain fixed in different contexts. I see very few advantages of rem over pixels.

Overall it is difficult to compare relative units like em to pixels directly because the behave in completely different ways. Designers and developers should be educated on the differences instead of being told to use only one or the other.

Comment by Scott Kellum on 07/20  at  09:01 AM

Hey Scott. Thanks for commenting; I’m thrilled you enjoyed the post.

For what it’s worth, the pixel-related arguments above were meant to be about the minor annoyances involved in converting designs from fixed-layout applications into fluid CSS layouts, not about comparing the use of em and px units within CSS.  Sorry if that wasn’t clear!

Comment by Scott (Filament) on 07/20  at  09:27 AM

Thanks everyone. There was enough feedback here about REM units that we posted a followup piece to discuss them in more detail.

Comment by Scott (Filament) on 07/20  at  10:23 AM

There is also a bug with 62.5% which exists in all versions of IE so far, which causes 62.5% to be interpreted as 62%. This isn’t an issue for font sizing as the rounding is normally OK, however if you are using widths in ems then your pixel rounding can cause major headaches, more info:

While there are some great points in this article, I find that the most productive reason for resetting my base font size is to match my vertical rhythm.

Comment by John Milmine on 07/22  at  04:24 AM

I use to stick to EMs exclusively for font-sizes, namely because I work for a company that builds web applications for pharmaceuticals and a lot of visitors to the sites have vision impairments so we have text-resize plugins on most sites.

At some point I was given the idea that using percentages for font-size properties was “better” and I’ve stuck to that ever since (though EMs I still use for things like margin of course).

Normally, with an HTML5 doctype, my document element (<html>) has its font-size set to 100%, and then I’ll modify the font-size on the <body> to be whatever the “norm” is for the site (typically 12px). Numbers get a little gross at times, but I’m use to it.

Do EM based media queries always pull from <body>, or do they pull from the document element?

Comment by Jeremy on 07/23  at  09:03 AM

I understand the use of the em for font but isn’t using ems for media queries slight overkill? screens aren’t calculated in ems after all. and devices register themselves at exact pixel widths and heights. why go through the extra work for something that won’t really affect usability?

Comment by Jeff on 07/23  at  03:17 PM

@Jeff - We design now for the content, not screen sizes so by using ems, we make out layout adapt to both screen sizes and font sizes.

here’s a very concrete reason why this is a good thing: In your browser, start bumping up the font size while looking at our site.

If you’re in a browser like Chrome, you’ll see that the layout gets messier as you increase the font size as words get so large the break out of their columns and een overlap each other.  Since the words get larger as font size increases, the same layouts no longer work as the font size increases.

Now refresh. You’ll see that if you made your font size large enough, you’ll actually cross a breakpoint and see a layout that fits the content correctly, even if that layout was originally designed for a smaller screen resolution. If you make the font really large, you’ll ultimately see the mobile layout because even though your screen may be 1,200 pixels wide, the font size is so large that the layout that will accomodate the words at that size is the simpler, single column mobile layout. 

Some browsers re-calculate as you bump up the font size which is a fun way to see this in action. Hope this helps explain why this is such a cool approach. The CoudFour article linked above walks through this in more detail.

Comment by Todd (Filament) on 07/23  at  03:33 PM

Interesting. I’ll have to check out the article, thanks.

Comment by Jeff on 07/23  at  03:39 PM

Don’t most browser stylesheets fallback to a pixel based default value anyways? 16px in most if I remember correctly. So 1em or 100% would be the same as the browser default of 16px, right? Let me know if I missed something there.

For responsive sites I’ll set:  body { font-size: 16px; } then all my other text elements will use emS. In my media queries I’ll change the body font-size which will cascade and relatively resize all the text elements throughout the layout since the em will cascade up to the pixel font-size of the body. It’s not pixel perfect but by changing one CSS rule you can relatively resize a whole layout.

I haven’t ran into any issues yet but I haven’t done a website like Boston Globe that might have tighter text containers than what I’ve done, in which case you might need quite a few breakpoints which change the body font-size.

Comment by Jesse on 07/23  at  08:29 PM

@Jesse: yes, you’re correct. You could set it to 100% or leave it alone, same idea.

Comment by Scott (Filament) on 07/24  at  02:19 PM

@jesse if you set your HTML or body font size in px then you won’t respect the base font size set by the user. Yes, most browsers default to 16 however this is customisable. It’s customisable not only on a website by website basis by hitting ctrl+ or - but also for every website in the browsers settings. Users with poor vision can raise the base font size from 16 to whatever they like. When you set your base font size in % you respect their setting, when you set it in px you override.

Comment by John Milmine on 07/25  at  05:27 AM

Great post, it convinced me to move away from the 62.5% reset.

However, I am redesigning my site and have noticed that Firefox 12.0 fonts seem to render slightly smaller that Chrome 20. Have you seen this before? Or know how to resolve?


Comment by John Whitman on 08/01  at  03:45 PM

Never mind on the previous comment...moronic error on my part.

Comment by John Whitman on 08/01  at  03:57 PM