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

There are some additional little syntax details, but this is basically all you need to know to actually make a media query work. Once you memorize this short, simple syntax and the various media features that are available, you could technically say that you know how to use media queries. But knowing how to use media queries effectively requires a whole lot more considerations than just where to put an @ or {.

Designing web layouts with media queries is a process. You need to keep them in mind from the very beginning and make decisions at several points about how to integrate them in ways that will make the most sense for your site. There are very few always-right or always-wrong answers. What type of media query set-up would work best will depend on your site, your users, and your own capabilities and experience. But I wanted to cover the pros and cons of some of the essential considerations that go into crafting robust media query-driven layouts. These considerations include whether to:

• Make the media queries embedded or external
• Overlap or stack your media queries
• Make mobile or desktop styles the default
• Use conditional comments or JavaScript to add support for IE 8 and earlier versions

This article is just as much for me as it is for you—it can be hard to keep track of all the different configuration variations you can use! Hopefully I’ll be able to make the pros and cons of the various approaches clearer so you can use this article to guide your decisions when you start a project involving media queries.

How to include your media queries: embedded vs. external

There are two ways to include media queries in your site: embed them within a style sheet or include them in a call to a separate, external sheet.

Here’s what an embedded media query looks like (pretend that we’re inside a style sheet):

body {
    background: gray;
}
@media all and (max-width:500px) {
    body {
        background: blue;
    }
}

For an external media query, simply extend the existing media part of the link element or @import rule:

<link href="narrow.css" rel="stylesheet" media="only screen and (max-width:500px)">

@import url(narrow.css) only screen and (max-width:500px);

Browsers that don’t support media queries won’t download these sheets, but browsers that do will download them all, regardless of whether they’re needed or not for the current viewing scenario. (The background images inside the currently-not-needed sheets won’t download, however.) On the one hand, this makes sense—the user could change his or her orientation or window size, and those alternate styles would suddenly need to be called into action. On the other hand, Greg Rewis found that even if you create a sheet that it seems like a device could never possibly use, such as a sheet for a max-width of 700 pixels never being needed by an iPad with its 768 x 1024 resolution, the device will download it anyway. But Chris Coyier pointed out to me that you could have an iframe in a page, for instance, that might need to use that smaller style sheet—so on the third hand, I guess this behavior is logical and unavoidable, if not perfect.

The pros and cons

* I’ll go into the details of both of these approaches to dealing with old versions of IE later on in this article, so sit tight if this IE stuff doesn’t make sense just yet.

The bottom line

In most situations, I think that embedded is the better way to go. I’ve never been a fan of separating out styles into separate sheets because I find it harder to keep things organized and easier to forget those extra sheets when debugging or updating. Plus, it adds extra HTTP requests, which are more expensive in terms of performance than having a single sheet that’s larger in file size. Because media-query-supporting browsers will download those extra sheets even they don’t currently need them, the smaller file size that you gain by separating the media queries into their own sheets is really only a benefit to browsers that don’t support media queries, as they won’t download those extra media query sheets.

But again—and this is the last time I’m saying this, but it applies to everything in this article—the best approach depends on your project.

How to use the cascade: overlapping vs. stacked

Regardless of whether you make your media queries embedded or external, you also need to decide whether you want them to overlap, bringing the cascade and specificity into play, or whether you want to “stack” them so only one media query applies at once.

Here’s what overlapping media queries look like (this example is embedded, but the same could be done with external sheets):

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:500px) {
    body {
        background: blue;
        font-family: serif;
    }
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
    }
}

Do you see how these media queries are not mutually exclusive? Both apply to windows greater than 700 pixels wide. If my viewport was 800 pixels wide, for instance, it would meet both the minimum width of 500 pixels and the minimum width of 700 pixels and apply the styles from both media queries. I’d have a red background with white text in a serif font.

When you overlap your media queries, the cascade and specificity come into play when determining which rules to use. For instance, if I used the same exact media queries containing the same exact CSS, but changed their order so that the min-width:700px one was first, I’d get different results:

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
    }
}
@media all and (min-width:500px) {
    body {
        background: blue;
        font-family: serif;
    }
}

Now my 800-pixel-wide viewport would have a blue background instead of red—the rule that comes later with the same specificity wins.

Instead of overlapping your media queries, you can stack or isolate them so that each is mutually exclusive:

body {
    background: gray;
    font-family: sans-serif;
}
@media all and (min-width:500px) and (max-width:699px) {
    body {
        background: blue;
        font-family: serif;
    }
}
@media all and (min-width:700px) {
    body {
        background: red;
        color: white;
        font-family: serif;
    }
}

Now only one of these media queries can apply at a time: the first applies in viewports between 500 and 699 pixels, and the second applies at 700 pixels and up. This means you don’t have to worry about cascade or specificity any more, but you do have to repeat any styles that you want to apply in both situations, such as font-family:serif in this example. On the other hand, you don’t have to override styles from earlier media queries that you don’t want to apply in the later media queries. So neither setup always leads to more or fewer lines of CSS.

Whether you overlap or stack also has an impact on which assets get downloaded in WebKit browsers. If you have multiple media queries that apply to the same situation (such as the 500px and 700px media queries both applying to the 800px viewport example above), WebKit-based browsers will download all the images in all of them, regardless of whether a later media query overrides one of the images in an earlier one. (This also happens with the styles outside any media queries, by the way.) This doesn’t happen if the media queries are stacked; in this case, WebKit will only download the images called for in the single, currently applicable one. (But again, it will download any images outside the media queries too, even if later overridden.) This handy information is from Greg’s “CSS3 Media Queries? Download Answers” and Cloud Four’s “Media Query Image Download Test.”

The pros and cons

The bottom line

I think overlapping media queries is more often than not the most efficient way to go. Most sites don’t have radically different looks between media queries—sure, the layout might appear very different, but things like the typography, colors, and various visual effects are usually the same. Because of this, I’ve found that in most cases you’ll end up writing a lot more lines of CSS if you stack your media queries and don’t get to take advantage of the cascade. (Hooray for the cascade!)

However, if you do happen to have a site that has very different styles in each media query, stacking may be more efficient than overlapping. Also, because of WebKit’s downloading behavior, if you’re switching a lot of images between media queries, it may be wise to stack those queries instead of overlapping them, even if that means more lines of CSS and more chance of forgetting to update a rule inside multiple queries.

Which styles to make the “default”: mobile vs. desktop

While it’s possible to put all of your styles inside media queries, you’ll almost never see this, as browsers that don’t support media queries will get no styles whatsoever. What usually happens is that a chunk of styles sit outside media queries, either inside your single style sheet or in their own style sheet using a standard @import call or link, and these essentially become your “default” or starting styles. You then layer on one or more media queries to form alternate styles for different scenarios.

Media queries aren’t just for creating different layouts for different screen sizes, but let’s face it, that’s their primary use right now—and a dang good one. So that’s what I’m focusing on here: whether to make the small-screen styles the default or whether to make wider-screen styles the default. A few caveats, however:

• For ease of writing, I’m just going to refer to the smaller-screen styles as “mobile” and the wider-screen styles as “desktop,” even though mobile styles might be viewed on desktop devices and vice versa, and even though not all mobile devices support media queries.
• Also keep in mind that even though I’m simplifying it to two options for ease of discussion, you can have multiple media queries for each of these scenarios (such as 320px, 480px, and 600px “mobile” styles and 760px, 960px, and 1200px “desktop” styles), and any of these could be your default. You don’t have to make one extreme or the other the default.
• Finally, I’m specifically talking about which styles you make the default in the CSS itself, not about which version of the layout you first design for when coming up with wireframes, comps, and what-have-you. In a certain project, it may make the most sense to plan for the desktop design first, but when it comes time to build the media queries, make the mobile styles first. Nathan C. Ford talks about this in “Design for a Target Experience First.”

OK, are we all good? Good. Moving on.

Once again, WebKit’s downloading behavior is a big factor here. If you make the desktop styles the default and then override some of its assets in a mobile media query, either by setting new background images or setting elements that contain background or foreground images to display:none, Safari on iOS will still download the overridden or hidden desktop assets. The reverse is true: when mobile styles are the default, desktop Safari and Chrome will download all the mobile assets, even if overridden or hidden by the desktop styles.

This behavior isn’t “wrong,” by the way. It’s common for browsers to download assets that are set to display:none, as it allows the content to be preloaded and ready-to-go if later revealed by a script, such as a hover effect over text that reveals a thumbnail image. WebKit doesn’t discriminate between situations where the currently hidden image might be needed later, such as if the user can and does resizes her viewport, or if it will never, ever be called into play.

If the downloading of the unneeded image is problematic in your case, there are a few ways to work around it:

• Cloud Four’s test page shows that if you set an image as a background on a div, and then instead of hiding the div you hide the div’s parent element, WebKit won’t download the image.
• You could simply choose to make your default styles neither mobile or desktop—just restrict them to basic text formatting, colors, and the like. Introduce layout and images only inside media queries.
• There are a variety of ways to use scripting to control what gets downloaded when. Read “Combining media queries and JavaScript” by Peter-Paul Koch for the general idea behind this, as well as “Responsive IMGs Part 2 — In-depth Look at Techniques” by Jason Grigsby for a discussion of a whole bunch of scripting techniques to load images on an as-needed basis.

These solutions won’t work with all sites, but they are options in some cases.

The pros and cons

The bottom line

In most cases, I would advocate making the mobile styles the default, as it allows old mobile browsers to see the correct mobile styles. Yes, desktop IE 8 and earlier will also see those mobile styles, but this is an easy to fix with some JavaScript—a much more quick and straightforward process than getting your mobile styles to apply to non-media-query-supporting mobile browsers when you make desktop the default. Also, the fact that mobile devices won’t have to download any of the assets you call in the media-query-desktop styles is a big plus, as mobile devices are more likely (but definitely not guaranteed) to have slower connections and more limited bandwidth than desktop devices. I’ve made mobile styles the default in the last two sites I worked on, and I anticipate this being my go-to method going forward.

While mobile-first design, as it’s been dubbed by Luke Wroblewski, has become quite popular, and I too will sing its praises, I don’t agree with those who say it’s the only viable way to craft media queries. Desktop-default has a fair share of merit too, as you can see in its pros list above. It’s a great way to retrofit an existing site, since you can add on a chunk of mobile styles instead of having to rewrite all the CSS from scratch. It’s also a great way to get your feet wet with media queries. Designing mobile-first is a big shift in both your mindset and design process, so sticking to desktop-first might be best on your first foray into creating a site utilizing media queries. In Chapter 6 of my book Stunning CSS3, I take a desktop-default approach, as I think this is an easier way to first learn media queries. The default styles are targeted towards a size that most desktop users will see, with styles for both wider and narrower versions layered on. This means that even if I didn’t use JavaScript to fix IE 8 and earlier, or if the JavaScript doesn’t load, users will still see a layout that will work well for the majority of desktop viewport sizes—just the same as they would before we had media queries as an option. Media queries are used as progressive enhancement, not a requirement.

How to deal with IE 8 and earlier versions: conditional comments vs. JavaScript

Speaking of IE, you probably know that Internet Explorer 8 and earlier versions don’t support media queries. Since these browsers are likely a big chunk of your audience, I suspect you’ll want to figure out a way to get your media queries to work in IE 8 and earlier. You have a couple options: use conditional comments to feed separate media query sheets to different versions of IE or use a pre-fab script to make media queries magically work in IE.

To use conditional comments, you’ll vary your approach based on which set of styles, mobile or desktop, are your default. In either case, you’ll need to have your media queries separated into external sheets, not embedded in a single sheet along with your default styles.

If desktop styles are the default and you want to use conditional comments, you don’t need to really worry about desktop versions of IE 8 and earlier—they’ll get the desktop styles automatically. Sure, they won’t get any variations on those desktop styles that you might have included to better fit every particular viewport size, but if you’re using media queries as progressive enhancement, this isn’t likely to be a problem. Sure, it’s not ideal if an IE user with an 1100-pixel viewport sees the default 700-960-pixel styles instead of the 960-and-up media query, but it shouldn’t be a deal-breaker—the layout they see isn’t likely to look broken or be unusable. They shouldn’t know anything is “wrong.” So there’s nothing extra that has to be done for desktop IE 8 and earlier in this desktop-default scenario.

But the default desktop styles have a much bigger impact in the mobile version of IE used on Windows Phone 7. Luckily you can target it using a conditional comment and feed it your mobile-specific sheet:

<link rel="stylesheet" href="global.css" media="all">
<link rel="stylesheet" href="mobile.css" media="all and (max-width: 700px)">
<!--[if IEMobile 7]>
<link rel="stylesheet" href="mobile.css" media="all">
<![endif]-->

If mobile styles are your default, the situation is basically reversed: mobile-IE is fine without any extra work, but you have to feed desktop-IE the desktop styles using conditional comments. Again, we’re in luck when it comes to conditional comment syntax: it’s possible to craft a conditonal comment that targets IE 8 and earlier—which includes the version of IE on Windows Phone 7—but then also explicitly excludes mobile-IE:

<link rel="stylesheet" href="global.css" media="all">
<link rel="stylesheet" href="desktop.css" media="all and (min-width: 700px)">
<!--[if (lt IE 9)&(!IEMobile 7)]>
<link rel="stylesheet" href="desktop.css" media="all">
<![endif]-->

I learned about this handy conditional comment trick from Jeremy Keith’s article “Windows mobile media queries.” That Jeremy is one clever guy.

Both of these conditional comment variations don’t actually make media queries work in IE—they basically feed an alternate, static layout to IE, not based on viewport size or anything other than IE version number and platform, without any ability to switch dynamically between states. If you need more robust media queries support in IE 8 and earlier, or if you want to be able to embed your media queries in a single sheet, you can instead simply link to a ready-to-use script that detects your media queries and makes them work in non-supporting browsers. There are currently two such scripts:

• Respond by Scott Jehl: This script is much smaller than the other, and when you resize your window, it makes the changes appear right away without any lag. It’s main downside is that it only supports the min-width and max-width media features (the only ones I tend to use anyway!). Also, I found it triggered some totally obscure IE bug in a layout I was working on recently. But in general, I don’t have any problems with this script and highly recommend it.
• css3-mediaqueries.js by Wouter van der Graaf: This script is bigger and slower than Respond, but it does support more media features and may be less buggy in some scenarios. It’s not my first choice, but it’s a great option too.

Both of these scripts will work in non-IE browsers too, by the way. If you want to limit them to IE so others don’t have to take the HTTP hit, hide the script call in a conditional comment:

<!--[if (lt IE 9)&(!IEMobile 7)]>
<script src="respond.min.js"></script>
<![endif]-->

The pros and cons

The bottom line

Plugging in a little script takes no effort whatsoever, so if you’re using embedded media queries, why not use one of the JavaScripts? For the small percentage of people using IE 8 and earlier with JavaScript turned off, I’m not concerned about them simply seeing the default styles; if mobile is default, they’ll get simple but readable and clean, and if desktop is default, it will probably look just right anyway!

Summing it all up

By now you’ve seen that there are lots of important decisions that go into how you set up your media queries for maximum efficiency, robustness, and ease of use. These decisions include whether to:

• Make the media queries embedded or external
• Overlap or stack your media queries
• Make mobile or desktop styles the default
• Use conditional comments or JavaScript to add support for IE 8 and earlier versions

Hopefully I’ve given you the information you need to make those decisions easier.

There are lots of other decisions you’ll need to make along the way that I haven’t covered, such as:

• Which media features to use (Use max-width or max-device-width? Use orientation? That sort of thing.)
• Which dimensions to target, aka the breaking points in the design
• Which units to use for those breaking points (Pixels or ems?)

Don’t let all these decisions scare you off using media queries. Just know that, like any design technique, you can go about it with careful consideration or you can just quickly slap some sloppy media queries on your site. Think through the pros and cons of your media query configuration so that your media queries don’t just work, but work well.

Related Posts:

• Media queries presentation at indieconf
• Examples of flexible layouts with CSS3 media queries
• Bug fixes for removing the inner shadow on iOS inputs
• There’s already a book on responsive web design. Want to win it?
• IE 7 button text redraw bug

Of course, 140 characters couldn’t capture his whole opinion on the subject, so he wrote a blog post followup. I strongly recommend reading it. I really agree with it.

Also, he later tweeted: “My new opinion, based on insight from commenters: You DON’T need to know how to write HTML/CSS. But in many scenarios it can be useful.”

I agree with this too, for the reasons explained well by Mark Boulton. A web designer doesn’t necessarily need to know how to write actual HTML and CSS. But she does need to know about the limitations imposed by browsers, the strengths and weaknesses of the medium. Writing HTML/CSS can make understanding and designing around these limitations a lot easier. But you can come to this understanding without learning HTML/CSS first.

Basically, my opinion is still the same as it was when I wrote Should web designers build their own pages? back in June 2008. Check that article out for my full opinion—including my very own architect analogy! (Seemingly a must whenever debating this topic.)

Related Posts:

• Should web designers build their own pages?
• Essential considerations for crafting quality media queries
• Me at The CSS Summit online conference
• The liquid web site motherload
• Voices That Matter: Web Design Conference 2009

While Andy’s proposal doesn’t just pertain to the design process for flexible sites—he seems to advocate it for all types of sites—Andy does ask:

Is the fact that so many web pages are fixed width and centered a direct result of clients signing off fixed width design visuals?

I’m willing to answer yes to that question. Not that this is the only reason fixed-width designs get created, but I’m sure it plays a role in many of them. As I talk a great deal about in my book, as well as the presentation I’ve made at a couple conferences lately, you can’t build a flexible page unless you’ve designed it to be flexible in the first place. You may design a page that must be fixed-width inadvertently, and won’t catch it until you go to build the page in (X)HTML and CSS. But if your client already signed off on the design when it was a static image, it’s now too late to change the design to make it liquid-compatible. Forcing yourself to build at least a rough version of the page before you present the design to the client is a great way of checking if your design is truly flexible-friendly. If you find that it isn’t, you can make design changes to avoid CSS headaches later.

A lot of the commentary surrounding Andy’s proposal has been that building pages for clients will take a lot more time that isn’t in the budget. I think this is a valid argument. But, I also agree with the arguments that this workflow method can actually be a time-saver—or at least that the extra time spent making the (X)HTML/CSS comp can be made up later. Andy says:

As I work almost as fast in markup and CSS as I do in Fireworks, I find that the overall time that I take designing and implementing that design is dramatically reduced as I am not duplicating work. It leaves me free to spend more time on fine tuning a design and I’m sure that my designs are all the better for that.

I’m right with Andy on this one. I’ll spend a lot of time futzing with the perfect border color or the perfect amount of spacing under a heading; when it comes time to build the page, I’ll have to do all that futzing over again in the CSS to find the perfect em measurement, for example, that matches the spacing I created in the Fireworks comp. It’s often faster for me to just leave all the work on these design details to my CSS development stage.

Another argument for time-saving comes from Kyle Weem’s response to Andy’s original post:

…you can absorb that extra time spent in the budget that would have been wasted on extravagant solutions generated to create identical rendering where it need not exist.

Another argument I totally agree with, especially if you are trying to create flexible designs. When you build the (X)HTML/CSS before showing to the client, you catch things in your design that are going to be tough and time-consuming to build—either because you’ve designed them in such a way that you can’t make things flexible, or it’s just going to take a lot of hacking to get it looking the same cross-browser.

All this said, this method of showing (X)HTML/CSS pages to clients instead of static design comps is not something I’ve actually done (though I do sometimes show wireframes before design comps). But as someone who primarily designs liquid layouts now, I can see it being really beneficial to the way I work, and I’m definitely going to give it a try soon.

Related Posts:

• 70+ essential resources for creating liquid and elastic layouts
• Why browser zoom shouldn’t kill flexible layouts
• Voices That Matter: Web Design Conference 2009
• Hiding and revealing portions of images
• Foreground images that scale with the layout

My answer in a nutshell: Ideally, yes.

I’ve been lucky enough to always design the pages that I build. I’ve worked at a design agency, as part of in-house design teams, and freelance, but never have I had a separate designer create comps to then hand off to me to build.

I call myself lucky in this regard because even though I’ve never experienced this design process firsthand, I’ve seen how frustrating it can be for other web designers. (Note that I said “can,” not “is.”) When the visual designer doesn’t know how to actually build web pages, he or she frequently designs in elements that just don’t work well on the web. Either they’re things that cannot be built with HTML and CSS—such as elements that depend on an exact font size—or they’re things that can be done but are either difficult or unwise to implement, due to current best practices in the areas of standards, usability or accessibility.

It’s been my experience that the more experience a designer has actually building web pages, the more successful he or she is in designing interfaces and graphic elements that work well with its strengths and constraints. That doesn’t mean that every designer should build his or her own pages; it’s fine to have a division of labor, and I’m sure it’s actually the smartest process in many teams. Nor does it mean that the designer has to be an advanced HTML or CSS developer. It simply means that the designer ought to have some idea how to build the page if he or she really had to.

Mark Boulton argues in his post “Design isn’t about tools” that “knowing how to build things in HTML/CSS limits your creativity.” I see his point and think it’s a really good one. We all have to be careful to not just keep designing things the same tired way because we’re used to building things a certain way. It can be a really positive, fun experience to drop a print designer into your comfy design nest to force you to consider new design possibilities, even if you can’t use them exactly as-is on the web.

But at the same time, it’s unrealistic to think that you can design without the constraint of any tools. At the Voices That Matter conference I was just at, Jason Cranford Teague gave a presentation on web typography in which he said that design is about constraint—working within it as well as overcoming it—and that if you want to work without constraint you’re an artist, not a designer. I think this applies to the question of whether designers should feel constrained by HTML and CSS, and I think the answer is yes. Architects don’t have to be qualified to build houses, but they have to have some idea of what construction techniques are possible, the physical characteristics of the materials they’re designing with, general physics, etc. They can’t just design buildings without any knowledge whatsoever of how they will ultimately be built.

Mark uses a print design analogy to ask “do print designers need to know how to build a press?” This analogy makes no sense to me. It’s like asking if web designers need to know how to build a browser, or a computer even. Of course not. The real question is “do print designers need to know how a press works”—and the answer to that is an emphatic yes. They don’t need to be qualified to actually operate a press, but they need to know the limitations and strengths of the printing press they’re work is going to be produced by. Print production processes are a pretty important part of the curriculum of any good graphic design program. (That last sentence had a lot of p’s in it!) Print designers need to know practical things like not to design important info within 1/8″ of the edge of a piece, not to run something that must be matched up perfectly across the fold of a multi-page book, what type of paper they’re going to be printing on, etc. I suppose you could call this being constrained by your tools—but it doesn’t necessarily follow that that’s a bad thing.

(On a little tangent, I applaud Jon Hicks for pointing out during this whole debate that Fireworks is a better tool for creating web comps than Photoshop. I switched to Fireworks for web work almost five years ago and can’t imagine going back.)

Related Posts:

• More debate on designers writing HTML and CSS
• Essential considerations for crafting quality media queries
• Me at The CSS Summit online conference
• The liquid web site motherload
• Voices That Matter: Web Design Conference 2009