@media all and (min-width: 500px) {}

@media screen and (max-width: 800px) {}

It’s a natural thought process: for windows or screens of particular width ranges, we want to flow our content in a particular way. This naturally seems like a pixel dimension. But, once again, to bring out my big hammer, what about when we look at things from a content perspective?
Folks who design for traditional reading media—where the content really is king—don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.
Thus actual column width is a function of font size and ems-per-line.

Baseline expectations

You may have seen the rule of thumb (useful, admittedly!) that makes the following general equation in terms of baseline font sizes in CSS:

100% = 1 em ~= 16px ~= 14pt

This means that, at your baseline, that is, before you’ve adjust font sizes in any child elements, the default font size in the browser is usually approximately 16px and usually approximately 14pt but always 100% and 1em.
If we start from a baseline of 16px, you may well wonder what the difference (beyond academic) is between a media query like:

@media all and (min-width: 400px)

and one like this, that uses ems multiplied against the 16px baseline approximation:

@media all and (min-width: 25em)

The answer, my friend, is content

Here’s the 64-dollar question or whatever:

What happens when the baseline is not 14pt/16px?

On Ye Olde Desktop Web, this situation most often comes about (“most often” is unscientific here, but I’m willing to toss out the hypothesis, at least) from user-intiated zoom in browsers. Low-sight users might do it, I know I do it when I’m surfing the web on my Mac Mini from the couch across the room. I’m not that old but, man, it’s hard to see the contents of a Wikipedia article on a 23″ monitor from 10 feet away.
As I zoom in, that is, make the text larger in my browser, I’m no longer at a 14pt/16px baseline. 100%/1em in my world is now a different number, maybe 18pt, maybe 32px. Pixel-defined content holders no longer have comfortable amounts of words per line. Pixel-defined content holders that float might wrap awkwardly as the content in them swells.

Case study: Our nav

Our creative director and CSS wizard extraordinaire, Aileen, whipped us up a beaut of a responsive new site layout. For various screen widths, our site’s nav has a few different behaviors.
In pixels at normal zoom, the nav elements fit in a line roughly at a width of around 656px. There’s generous room to detatch and float next to the logo at around 960px.
For screens/windows narrow enough that the full set of top-level nav elements would not fit on one line, we use the menu button nav pattern:

But what happens if a user has his or her zoom set higher?

I’ll show you a little experiment. I’m using the Chrome browser, and I’m viewing our site with a window about 670 pixels wide. With a pixel-based media query, that puts me in the second category of nav experience: all of the top level items are shown horizontally, docked to the top of the content:

OK, now I’m going to use the Zoom In command twice to make my text larger.
With a pixel-based media query:

 

With an em-based media query:

Why did this happen?
The pixel-based media query @media all and (min-width:656px) still evaluates to true with the zoomed-in text and therefore creates awkwardly-wrapped nav elements.
However, the em-based media query of @media all and (min-width: 41em) scales to the larger text size. Zoomed in like this, the browser no longer satisfies that query: we have fewer than 41ems to work with. So we deliver the menu-button nav pattern and other layout and styling appropriate for the way the text fits. Content, again, is what ends up dictating what we’re doing in the end.
You could also make the text smaller and watch the same proportional adjustments occur, in the inverse.
BTW: It should be noted that, unlike window resizes, which cause media queries to be re-evaluated immediately, you’ll need to reload the current page if you zoom in or out for em-based media queries to re-apply. My hunch is that most users who zoom a lot keep their zoom set as they navigate around different pages and aren’t changing zoom settings on a site-by-site basis. I could be wrong about that, though.

The specifics of em-based media queries

The media queries on our site are all crafted based on the approximate baseline. We played with our browser window widths, adjusting them until it looked like they were at the appropriate width to create a breakpoint at normal text zoom. We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.