A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

On a more practical level, achieving a Bruce Lee-like command of the fluid web means ditching the pixels and points for flexible units like ems or percentages. There’s a lot more to responsive design than just fluid layouts, but it’s definitely a key part of the process.

Curiously, when it comes time to use the other universal element of responsive design — the @media query that applies the actual responsive design — most of us revert right back to pixels with something like @media all and (min-width: 500px) {}. It seems logical; after all, you’re trying to fit your content into a window with specific dimensions, so why not use pixels?

Certainly you can, and most sites we’ve seen up to this point use pixels for the actual media query breakpoints, but it’s worth noting that you can use ems here as well.

Lyza Gardner over at Cloud Four recently posted a look at why Cloud Four’s new responsive design uses ems in its media queries. Here’s her reasoning for Cloud Four’s em-based approach:

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.

The rest of the post walks through how Cloud Four used em-based media queries to create a better navigation experience on their site. Some of the advantages may not apply to every responsive design, but there is one additional benefit that works nearly everywhere — em-based media queries mean that your site will handle user zooming much better, applying media queries instead of allowing content to overflow its container.

But perhaps the best part of an em-based approach is that it seems to work in nearly every web browser. Cloud Four’s post doesn’t get into the specifics of their browser testing so I fired up a couple of virtual machines and tested their site and my own simplified demo page in every major browser.

According to my testing, em-based media queries work properly in all OS X browsers. (I tested the latest versions of Safari, Firefox, Chrome and Opera.) Only Firefox and Opera apply media queries on zoom, though. (Chrome and Safari need a page refresh before the query is applied.)

On Windows 7 Firefox, Opera and Chrome behave the same way they do on OS X. IE 9 also worked fine and, like Firefox and Opera, applies media queries when zooming without needing a page refresh. Judging by the comments on the Cloud Four blog, Chrome on Linux may have some issues, but in my testing Firefox and Chrome on Fedora worked as expected.

All the mobile browsers I tested on Android worked as well (Firefox, Chrome, Opera Mini and the default Android browser). On iOS Mobile Safari applies em-based queries as you would expect.

In the end you certainly don’t need to use em-based media queries. As many sites out there demonstrate, pixel-based queries work. At least for now. However, as a wider range of screen sizes begin to access the web switching to em-based queries may put you ahead of the game. Em-based queries mean addressing the content-width rather than just the screen width and that feels like a more future-friendly approach.

Go out for a chai latte with your local technology soothsayer (or just study your Google Analytics reports) and it’s pretty clear that the mobile web is the future.

But let’s not call it the mobile web, let’s call it the smaller web. And by smaller, I mean a web with less available screen real estate than the desktop.

While the iPhone may have a fully-capable web browser, it still has a relatively small screen. Serving the desktop version of the your website is hardly the best way to deliver your content to iPhone owners.

And don’t forget that the iPhone people are the lucky ones. The latest devices — iPhones, iPads, Android phones — have relatively large screens by mobile standards, but these devices are in the hands of a very slim percentage of worldwide mobile users. There are some 3 billion users out there with older phones, or devices with crappy browsers and very small screens.

The point here is that you need something far better than the desktop-optimized version of your website to offer to mobile visitors.

Mobile Solutions

There are three popular ways to approach mobile sites:

• Write good code, but do nothing special for mobile. This works fine if your audience is made up of iPhone, iPad and Android users with nice, high-speed 3G connections. That’s about 1 percent of the mobile market, but some sites with an abnormally large number of iPhone users (like an iPhone news site) can get away with it.
• Detect the device in use and serve a separate mobile site. Something like m.flickr.com. While this approach works, it means maintaining a second website, plus constantly updating your device detection scripts as new gadgets come on the scene.
• Build an adaptive site using CSS 3 media queries. Thanks to CSS 3 and the new media query syntax, you can build a site that automatically adapts its layout to fit the screen size of your visitors.

The later approach has received the most attention lately, with many designers moving to fluid grids that reflow content, resize images and nicely smoosh themselves down to fit any screen. Check out Simon Collison’s personal site, or designer Jon Hick’s website for examples of media queries in action.

Be sure to resize your browser window so you can see the content reflow as the browser width shrinks. That’s the gift of media queries — by precisely labeling your CSS, the presentation can be altered dynamically depending on the device’s screen width and height. Your content never changes, and neither does your CSS. The page simply adapts.

However, as nice as media queries are, before we dive into the syntax and how it can help, it’s important to realize that this approach is not going to magically solve all your mobile design problems.

Problems with CSS 3 media queries

The media query approach will work fine for many sites, but won’t help when it come to bandwidth concerns. Just reflowing the visual design of your content to fit smaller screens doesn’t make your images download any faster, nor does it compress or simplify your HTML.

There are also a host of older mobile browsers that doesn’t understand media queries and will simply fail to load your mobile site styles.

While media queries are not, in the words of web developer Jason Grigsby, “a silver bullet,” they can still be quite helpful provided you use them properly.

Ethan Marcotte’s tutorial on A List Apart helped generate interest in media queries as a solution for mobile devices, and it’s well worth a read. Marcotte shows how to bolt media queries onto a desktop design so that it gracefully degrades on smaller screens, reflowing content to fit the available space.

It’s a very well done tutorial, but it essentially approaches the problem backwards.

I’d argue that the best way to use media queries is not to shrink your site for mobile, but to enhance it for the desktop. That is, start with a style sheet that creates a nice, narrow, simplified, single column layout for mobile visitors and then uses media queries to expand the layout for desktop browsers.

Progressively enhancing your mobile site

Using media queries is actually quite simple, the syntax is very similar to the “media types” syntax that arrived in CSS 2.1. Media types allow you to specify a style sheet for screens and another for print. CSS 3′s media queries are similar, but target specific screen sizes (and orientation, though that syntax is less widely supported).

For example, let’s say we have two sections in our mobile site — a main column of content wrapped in an article tag, and a “sidebar” wrapped in an aside tag. For our mobile layout we’ve simply let the sidebar fall below the main content in a single column. But for the desktop we want to floated the sidebar to the right for a two column layout. To do that using a media query, the code would look something like this:

article#main, aside#sidebar {
    color: #222;
    ...more mobile styles here...
}
@media screen and (max-width > 800px) {
  #main {
    float: left;
  }
  #sidebar {
    float: right;
  }
}

This chunk of code tells any browser with a screen larger than 800px to float our content into two columns. Because all modern web browsers understand media queries, this works almost everywhere. Internet Explorer 8 and below will not do anything with this code, but chances are you’re already writing IE-specific style sheets so you can simply write the rules there — minus the @media syntax — and IE will fall in line.

Mobile browsers will naturally ignore this rule. But of course, they will download the entire style sheet which includes all our @media rules. Given the bandwidth constraints of mobile networks, anything we can do to decrease files size is going to help. Fortunately, there’s another way to use @media — include separate style sheets for desktop browsers.

The @media query syntax works in your head tags as well, which means we can simple write a separate style sheet for desktop browser and ensure that only they see it, but using a tag like this:

<link rel="stylesheet" type="text/css"
  media="screen and (max-width > 800px)"
  href="/css/desktop.css" />

The code above also loads our desktop styles only to devices with larger screen resolutions, but this time it does it without bloating our base style sheet for mobile devices.

Of course nothing awesome in web design is accomplished without some sort of trade off. We’ve decreased the size of our mobile style sheet, but we’ve added an extra HTTP request to our desktop site. If you’ve ever used YSlow or PageSpeed to evaluate your load times, you know that extra HTTP requests make for slower page loads.

Whether or not the tradeoff is worth it is your call. In most cases, one extra HTTP request probably isn’t going to dramatically slow your page, but it is something to keep in mind, particularly if you start adding another style sheet for the iPad and other tablet-size screens.

While extra requests on your desktop site are a small drawback, there are other, more complicated problems that @media queries won’t solve.

Issues with images

The wrench in the works of any mobile-first web design strategy is the use of images. Large images slow down mobile pages and, unfortunately, media queries don’t help with that. Obviously, when it comes to optimizing your images for mobile, CSS and @media queries — cool as they are — are not going to have the answer.

If we’re start by designing with mobiles in mind and serve smaller, more compressed images in our markup, the mobile visitors benefit and we’ve solved a large part of the problem. But then the desktop visitors have to suffer through your crappy, low-res images.

One solution is to use JavaScript to swap out the small images for another set of larger, higher resolution images on the desktop. Mobile platform consultant Peter-Paul Koch has a nice overview of how JavaScript can be combined with media queries to swap out your mobile-size images with larger ones for larger screens.

But in addition to requiring JavaScript for this solution to work, it also means our CMS or other site management tools now need to store and track two (at a minimum) sets of images.

However, that’s probably better than loading big images and forcing mobile browsers to scale them, which is worst of both worlds — large image downloads and processor-intensive downscaling.

The truth is there’s no easy way to solve the image problem. If the site you’re designing relies heavily on large images, you may be better off with a separate mobile website and a CMS that can automatically resize and keep track of both sets of images.

Conclusion

Media queries have been touted as the one-stop solution to all your mobile needs, but in fact they aren’t going to live up to that hype. Media queries are incredibly useful and work in most browsers, but in the end they are just another tool, not a total solution to everything.

Media queries are not the best approach in every case. The websites from Hicks and Colly are elegant examples of media queries (though both use different approaches) but the same technique just isn’t going to work for The New York Times. The complexity and depth of the NYT website (or Flickr, or Wikipedia for that matter) make a completely separate mobile website a necessity.

At the same time, there are numerous mobile websites out there that could easily have been built with media queries and would probably have spared their development teams quite a bit of extra work.

As with most things in web development, media queries are another tool for your toolbox. When and where to use them is something you can judge on an individual, by-project basis.

Photo: Jon Snyder/Wired

See Also:

• Slide Show Time: Rethinking the Mobile Web
• A Guide to Internet Explorer 9’s HTML5/CSS 3 Support
• How to Speed Up Your Site With YSlow and Page Speed