Switching to Em-Based Media Queries

CssResponsive DesignMedia Queries

Css Problem Overview


Now that the WebKit page-zoom bug has been fixed, what are the main reasons for using em-based media queries rather than pixel-based media queries?

Bounty

I'm adding a bounty to my question because so many prominent CSS frameworks and web developers use em-based media queries that I'm convinced there must be good reason(s) for doing so.

The one advantage I'm aware of is that if a user changes the default font size in their browser, content will squeeze in a manner similar to the issue solved by the page-zoom fix. Is there any data to show people actually do change the default size rather than zoom?

Note

To make my question more focused, I removed two peripheral items. The original post will add perspective to @nwalton's great answer, which addressed all three points I asked about.

Css Solutions


Solution 1 - Css

  1. In modern browsers there should be no difference between em-based and pixel-based media queries if the browser handles the zoom correctly. I actually had trouble with em-based media queries in one project because in one of the media queries the base font size changed and then all of the other media queries got messed up. That may have just been a stupid mistake, but you get the idea. I'd go with pixels. See update below. While zoom does not have an effect on modern browsers, base font size still does.

  2. The biggest problem I see you could run into with the 62.5% technique and rem is if you run into browsers that don't understand it. If you're worried about that you could add a fallback for less-capable browsers, and set rem for the modern ones.

     html { font-size: 62.5%; }
     body { font-size: 14px; font-size: 1.4rem; }
     h1   { font-size: 24px; font-size: 2.4rem; }
    
  3. If there's any difference in how fast browsers process px vs em, it's not noticeable. Browsers calculate CSS really, really fast (much faster than JS). So it's probably not worth worrying about.


Measurement pros, cons, and uses

px

I have used px for media queries in the past because they're so reliable and, like you say, they zoom just fine. Update: However, if a user changes their default style sheet, your media queries will be off.

  • Independent of CSS cascade
  • Mostly non-relative measurement (just depends on how the browser measures font pixels)
  • Zoomable in all modern browsers

em

Ems are awesome for making flexible grids and measurements. For example, if a container width is specified in ems, I can proportionally resize the container and its contents in my media queries with one declaration.

  • Responds to the CSS cascade
  • Relative to the container font size
  • Zoomable in all modern browsers

In this example, resizing the font also resizes its container proportionally.

h1.title {
  font-size: 2em;
  width: 20em;
  background-color: #baff1e;
}

@media (min-width: 400px) {
  h1 {
    font-size: 2.5em
  }
}

rem

I haven't actually used rem much, but I can see why a lot of people like it. You've got the power of a relative unit, but you don't have to deal with the crazy stuff that can happen when you throw in the CSS cascade.

Sizing things based on the browser's base font size seems like the web-standards thing to do, because then you allow for browsers whose optimal base font size might not be 16px. In practice, though, it kind of works the other way. From what I've seen, browsers use 16px as the base font size because that's what everyone expects, and set the actual size of that CSS measurement to look decent in the browser.

  • Independent of CSS cascade
  • Relative to base font size
  • Zoomable in all modern browsers

A note on the 62.5% technique

This has been around for quite awhile, and right now I don't know any reason not to use it. There was a 2007 article on A List Apart where they did some tests and found that font sizes displayed more reliably across browsers when the base font was declared at 100% and text was sized in em. But I'd be surprised if any of the browser constraints listed there are really relevant anymore. I still have a hard time feeling good about setting my base font size to 10px, but that's probably just personal preference.


Update

After doing some tests, I'm reversing my practice of using pixels for media queries. I'm now recommending em:

  1. Users do change their base font size. One thread on the Mozilla support network, "How can I increase the browser default font size?" has over 5,000 views. And a similar thread has over 15,000. Another study found a percentage of users (0.3%) who did have a default font size smaller or larger than 'medium'. How often users actually change it seems irrelevant (see a previous SO answer). If some people do, it's probably worth supporting them.

  2. Ems are likely more future-proof. They will work for any device whose optimal default font size is not 16px (as well as those that are).

  3. The thing that convinced me the most was to see it in action. Here's a codepen demo. Notice that the browser's zoom probably makes no difference (I tested in Chrome). But if you actually go into your browser's settings and change the default font size from "medium" to something else, the widths are way off. In my opinion, this is unacceptable.

Solution 2 - Css

I haven't yet found any data specifically on users who change their base font size, but I did some checking into websites that have been designed by people who ought to know what they're doing. I was looking specifically at whether they used px or em to specify their media queries. While this may not answer the question entirely, I think it adds some interesting dimension to the discussion.

Some Major Players

This list is by no means exhaustive or measured in any way except that it includes the names of individuals or groups off the top of my head who seem to be at the forefront of web development, or have contributed to responsive design practice in some way.

One interesting thing to note is that the last entry, Nicholas Gallagher, is the person who added the media query line to the HTML5 Boilerplate CSS. In that code he uses em, though on his personal site the media queries are set in px. I looked for discussion on that commit, but couldn't find any.

A Few of Their Sites

Again, a bit of a scattered list, but it contains a few sites that I consider worth looking at. Most of these have been built in full or in part by people from the previous list.

An interesting note with HTML5 Boilerplate, the main project's CSS uses em while the mobile version of the project uses px.

Mega-Sites

It was actually really surprising how few of the most popular sites on the web have any media queries at all. Here are a few who do use media queries.

Conclusion

Inconclusive.

It looks like people are using both methods with success, and there doesn't seem to be agreement as to best practices.

I sort of get the feeling that some of the more progressive designers are moving to em, but I have no data for that other than it just "seems" like that might be the case. It could also be true that some of the sites listed above are older than others, and have not been updated since people started moving to em-based media queries. It's hard to really get enough data to draw a good conclusion on that front.

However, the fact that some of the biggest sites in the world are using px tells me that this approach must might still be technically sound. If there were major problems with it, I'm sure the bigger sites would have heard about it from their users or from their testing, and moved to something more technically viable to serve their audiences.

Solution 3 - Css

There is one main reason why to use EM based media queries and that is
respect the users (base) font size setting
without breaking your layout!

You really should never ever neither define font-sizes in pixel (nor your elements width/height)!!!
Let the user decide what font-size he likes to look at your site.

So it is a question of accessibility.

If you are using pixel values, you have to assume a certain (base) font size, which is "normally" 16px. But not always, and that's the point. So if an user has chosen a smaller or larger (base) font size, your layout will fall apart.

Or on desktop systems, if the user uses the browser's zoom function he will get a horizontal scrollbar (which is mostly undesired).

All of this can be avoided by using relative units like EMs. And they have no drawbacks.

It is also worth mentioning that actually the base font size setting, as well as the zoom functionality in mobile browsers (on touch devices like tablets and samrtphones) work differently compared to their desktop counterparts. For the mobile browser versions the font size setting doesn't play such an important role as for desktop browsers. But again you do nothing wrong by using EM based media queries. And imho this is as "future proofed" as possible.

And you can easily use the "62.5% technique" as well.
Be reminded that the new "root em" font size depends on the root element's (of the page) font size and that is the html element, not the body element.

Use the "62.5% technique" without breaking accessibility:

html {
    font-size: 62.5%; /* with the standard base font size of 16px this will be equal to 10px */
}

body {
    font-size: 160%; /* 160% of 10px ~ 16px, understood by all browsers */
    font-size: 1.6rem; /* 1.6 * 10px ~ 16px, understood by all major browsers and IE9+ */
}

So you can use rem just as if it where px (divided by 10),
but without doing any harm to the user's settings!

No matter what base font size the user has chosen the font ratio will always stay intact.
And also your layout! ;-)

One final remark:
Always use min|max-width media queries and never device-width! The reason in short is that you layout and setting your breakpoints depending on your content and never on resolutions of any devices!

So by using relative units (like EMs) for your layout and font sizes your design is really "responsive". By using absolute units (like PX) it is not!

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestioncanteraView Question on Stackoverflow
Solution 1 - CssnwaltonView Answer on Stackoverflow
Solution 2 - CssnwaltonView Answer on Stackoverflow
Solution 3 - CssNetsurferView Answer on Stackoverflow