OFFLINE

Thankfully, the W3C created media queries as part of the CSS3 specification, improving upon the promise of media types. A media query allows us to target not only certain device classes, but to actually inspect the physical characteristics of the device rendering our work. For example, following the recent rise of mobile WebKit, media queries became a popular client-side technique for delivering a tailored style sheet to the iPhone, Android phones, and their ilk. To do so, we could incorporate a query into a linked style sheet’s media attribute:
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />
The query contains two components:

1. a media type (screen), and
2. the actual query enclosed within parentheses, containing a particular media feature (max-device-width) to inspect, followed by the target value (480px).

In plain English, we’re asking the device if its horizontal resolution (max-device-width) is equal to or less than 480px. If the test passes—in other words, if we’re viewing our work on a small-screen device like the iPhone—then the device will load shetland.css. Otherwise, the link is ignored altogether.
Designers have experimented with resolution-aware layouts in the past, mostly relying on JS-driven solutions like Cameron Adams’ excellent script. But the media query specification provides a host of media features that extends far beyond screen resolution, vastly widening the scope of what we can test for with our queries. What’s more, you can test multiple property values in a single query by chaining them together with the and keyword:
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />
Furthermore, we’re not limited to incorporating media queries in our links. We can include them in our CSS either as part of a @media rule:
@media screen and (max-device-width: 480px) { .column {  float: none; }}
Or as part of an @import directive:
@import url("shetland.css" screen and (max-device-width: 480px);
But in each case, the effect is the same: If the device passes the test put forth by our media query, the relevant CSS is applied to our markup. Media queries are, in short, conditional comments for the rest of us. Rather than targeting a specific version of a specific browser, we can surgically correct issues in our layout as it scales beyond its initial, ideal resolution.
Adapt, respond, and overcome
Let’s turn our attention to the images at the base of our page. In their default layout, the relevant CSS currently looks like this:
.figure { float: left; margin: 0 3.317535545023696682% 1.5em 0;  /* 21px / 633px */ width: 31.121642969984202211%;       /* 197px / 633px */}li#f-mycroft,li#f-winter { margin-right: 0;}
I’ve omitted a number of typographic properties to focus on the layout: Each .figure element is sized at roughly one third of the containing column, with the right-hand margin zeroed out for the two pictures at the end of each row (li#f-mycroft, li#f-winter). And this works fairly well, until the viewport is either noticeably smaller or wider than our original design. With media queries, we can apply resolution-specific spotfixes, adapting our design to better respond to changes in the display.
First of all, let’s linearize our page once the viewport falls below a certain resolution threshold—say, 600px. So at the bottom of our style sheet, let’s create a new @media block, like so:
@media screen and (max-width: 600px) { .mast, .intro, .main, .footer {  float: none;  width: auto; }}
If you view our updated page in a modern desktop browser and reduce the size of your window below 600px, the media query will disable the floats on the design’s major elements, stacking each block atop each other in the document flow. So our miniaturized design is shaping up nicely, but the images still don’t scale down that intelligently. If we introduce another media query, we can alter their layout accordingly:
@media screen and (max-width: 400px) { .figure, li#f-mycroft {  margin-right: 3.317535545023696682%;  /* 21px / 633px */  width: 48.341232227488151658%;     /* 306px / 633px */ } li#f-watson, li#f-moriarty {  margin-right: 0; }}

Our figures can responsively change their layout to better suit smaller displays.

Don’t mind the unsightly percentages; we’re simply recalculating the widths of the fluid grid to account for the newly linearized layout. In short, we’re moving from a three-column layout to a two-column layout when the viewport’s width falls below 400px, making the images more prominent.
We can actually take the same approach for widescreen displays, too. For larger resolutions, we could adopt a six-across treatment for our images, placing them all in the same row:
@media screen and (min-width: 1300px) { .figure, li#f-mycroft {  margin-right: 3.317535545023696682%;  /* 21px / 633px */  width: 13.902053712480252764%;     /* 88px / 633px */ }}
Now our images are working beautifully at both ends of the resolution spectrum, optimizing their layout to changes in window widths and device resolution alike.

By specifying a wider min-width in a new media query, we can shift our images into a single row layout.

But this is only the beginning. Working from the media queries we’ve embedded in our CSS, we can alter much more than the placement of a few images: we can introduce new, alternate layouts tuned to each resolution range, perhaps making the navigation more prominent in a widescreen view, or repositioning it above the logo on smaller displays.

By designing responsively, we can not only linearize our content on smaller devices, but also optimize its presentation across a range of displays.

But a responsive design isn’t limited to layout changes. Media queries allow us to practice some incredibly precise fine-tuning as our pages reshape themselves: we can increase the target area on links for smaller screens, better complying with Fitts’ Law on touch devices; selectively show or hide elements that might enhance a page’s navigation; we can even practice responsive typesetting to gradually alter the size and leading of our text, optimizing the reading experience for the display providing it.
A few technical notes
It should be noted that media queries enjoy incredibly robust support among modern browsers. Desktop browsers such as Safari 3+, Chrome, Firefox 3.5+, and Opera 7+ all natively parse media queries, as do more recent mobile browsers such as Opera Mobile and mobile WebKit. Of course, older versions of those desktop browsers don’t support media queries. And while Microsoft has committed to media query support in IE9, Internet Explorer currently doesn’t offer a native implementation.
However, if you’re interested in implementing legacy browser support for media queries, there’s a JavaScript-tinted silver lining:

• A jQuery plugin from 2007 offers somewhat limited media query support, implementing only the min-width and max-width media properties when attached to separate link elements.
• More recently, css3-mediaqueries.js was released, a library that promises “to make IE 5+, Firefox 1+ and Safari 2 transparently parse, test, and apply CSS3 Media Queries” when included via @media blocks. While very much a 1.0 release, I’ve personally found it to be quite robust, and I plan to watch its development.

But if using JavaScript doesn’t appeal, that’s perfectly understandable. However, that strengthens the case for building your layout atop a flexible grid, ensuring your design enjoys some measure of flexibility in media query-blind browsers and devices.
The way forward
Fluid grids, flexible images, and media queries are the three technical ingredients for responsive web design, but it also requires a different way of thinking. Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts. That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.
But that kind of design thinking doesn’t need to be our default. Now more than ever, we’re designing work meant to be viewed along a gradient of different experiences. Responsive web design offers us a way forward, finally allowing us to “design for the ebb and flow of things.”