You can view the slides on SlideShare, or download the slides here:

CSS3: Using media queries to improve the web site experience (PDF, 2.4 mb)

Here are several links to related resources, some of which are in the slides plus many that were not but which I recommend and think you’ll find useful.

Media query articles, tutorials, and tools

• “Essential considerations for crafting quality media queries” by me
• Excerpt of Chapter 6 of Stunning CSS3 on media queries by me
• “Design for a Target Experience First” by Nathan C. Ford
• The Goldilocks Approach by Front design agency
• “21 top tools for responsive web design” by Denise Jacobs for .net Magazine
• “Responsive Web Design Guidelines and Tutorials” by Smashing Magazine
• “An introduction to meta viewport and @viewport” by Andrea Bovens for Dev.Opera
• “Why images appear blurry on mobile devices” by Christopher Cohen

Dealing with IE 6-8 support

• Respond script by Scott Jehl
• css3-mediaqueries.js script by Wouter van der Graaf
• “Windows mobile media queries” by Jeremy Keith
• “Targeting mobile-optimized CSS at Windows Phone 7” by IE Mobile Team

Fluid/liquid layout

• Flexible Web Design: Creating Liquid and Elastic Layouts with CSS book by me
• “70+ essential resources for creating liquid and elastic layouts” by me

Media query inspiration

• Mediaqueri.es gallery
• My media query inspiration bookmarks on delicious and Gimmebar
• My liquid layout inspiration bookmarks on delicious and Gimmebar
• “Examples of flexible layouts with CSS3 media queries” by me

Related Posts:

• Essential considerations for crafting quality media queries
• There’s already a book on responsive web design. Want to win it?
• Examples of flexible layouts with CSS3 media queries
• Adobe MAX slides and resources
• Web Directions USA slides and resources

@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

“Screen readers, list items and list-style:none“

Roger found that some screen readers won’t announce list items if list-style:none is set on the list. (They will announce the list as a whole, just not the individual list items.) This very common bit of CSS visually represses the list markers, of course, but (probably?) shouldn’t change the spoken output. Unfortunately, this falls squarely into the “good to know, but what do you want me to do about it?” camp. Just keep it in mind, and hopefully the offending screen readers will fix this behavior soon.

“Using display:table has semantic effects in some screen readers“

Same sort of thing, only with display:table. NVDA in Firefox as well as the ORCA screen reader incorrectly announce elements that you’ve set to display:table as actual, semantic tables. This might be an area where you do have other options than using display:table (as opposed to list-style:none, where there are no alternatives if you don’t want markers), so this screen reader quirk is a little more helpful to know. I wouldn’t consider this a deal-breaker, but if you can easily avoid it, I say why not? If you can’t really avoid it, I wouldn’t sweat it, but again, keep it in mind.

“Styling button elements to look like links“

This is a useful CSS snippet for when you want something to look like a link (plain text) but act like a button (initiate an action other than taking someone to a new page). Roger points out, of course, that it would be better if the design were changed so that things that act like buttons look like buttons, but this is a good option when you can’t convince those darn designers to change things! (I’m allowed to jokingly complain about designers since I am one.)

Related Posts:

• Web accessibility presentation and resources
• Videos of screen readers using ARIA, updated
• Videos of screen readers using ARIA
• Media queries presentation at indieconf
• IE 7 button text redraw bug

I’m working on some styled buttons, created with the <button> element and some pretty basic CSS. In IE 7, if you scroll down the page so that the buttons move out of the viewport, then scroll back up to reveal them again, you’ll see lines of missing pixels drawn across the text of the buttons. It varies each time you scroll, so sometimes you won’t see any lines, and occasionally the entire text will disappear. The lines appear most often with the buttons with the largest text, but I think this is mainly just due to there being more pixels there to draw lines through, increasing the likelihood that IE 7 can screw it up. Hovering over the buttons or refreshing the page restores the text.

You can see a screenshot of the bug below, and view the bug live in IE 7 in my test page.

The buttons in IE 7 have lines drawn through their text, as if little strips of the text were erased.

I found a blog post that said that adding a one-pixel transparent border fixed the bug. I tried this and found that it does indeed fix the bug, but only if you remove either background-color or font-size. Both of those properties trigger the bug to begin with, and the border fix seems to only have enough power to fix one of the triggers, not both. I can’t remove either of those properties, so the border fix is a no-go. (Plus, the border does not actually show as transparent when I tested it, which makes it a deal-breaker anyway.)

Through experimenting, I found that removing overflow:visible also solves the bug. Unfortunately, that brings back the excess padding button bug that IE 7 and IE 6 suffer from. Setting overflow:visible seems to be the only fix for this bug, so this too is a property I can’t remove.

I of course tried the standard fixes of adding zoom:1 and position:relative, but neither of these, either together or separately, had any effect on the buttons.

I’ve tried so many things and I’m out of ideas. Can anyone help?

Related Posts:

• Bug fixes for removing the inner shadow on iOS inputs
• Media queries presentation at indieconf
• Essential considerations for crafting quality media queries
• A few links: CSS and accessibility
• There’s already a book on responsive web design. Want to win it?

Sounds like an easy fix, right? But if you didn’t read the comments on Trent’s article, you might have missed two important bugs* connected to using -webkit-appearance to remove the inner shadow:

1. If you use caret, it removes not just the inner shadow but also the borders on desktop versions of Safari and Chrome (as well as the beta version of the WebKit-based browser on the TouchPad tablet).
2. If you use none, it removes the inner shadow and leaves borders alone, but it disables focus styles on iPad.

In the case of the missing focus, I haven’t been able to confirm this myself; I don’t have an iPad, but the people I’ve asked to test it for me (thanks Josh!) have said the focus styles do show up, even when -webkit-appearance: none is set. Perhaps it’s a case of the version of iOS in use, perhaps the person who reported this bug in the comments to Trent’s article was simply having a problem with his individual machine, or perhaps there was something else in the CSS that was truly responsible for the problem. So it’s still not clear to me whether the second bug I listed above is really present. Do any of you iPad users have a problem seeing the red outline on focus in my test page?

If both of these bugs are truly present, they severely limit the circumstances in which -webkit-appearance can be used to remove inputs’ inner shadows. Luckily, we can use a background image instead of -webkit-appearance to remove the shadow. But what if you don’t want any background image to show? Simple—make the background image invisible. Some smart people on Stack Overflow suggested a couple ways to do just that:

1. Tile a transparent GIF as the background image.
2. Add a CSS3 gradient that runs from transparent white to transparent white.

I think the gradient option is ideal because it doesn’t require an extra hit to the server to retrieve the transparent GIF. And there’s no need to worry about lack of browser support, since the only browsers we want to apply the gradient are Safari on iOS.

Here’s what the CSS would look like for the gradient:

background-image:-webkit-gradient(linear, 0% 0%, 0% 100%, from(hsla(0,0%,100%,0)), to(hsla(0,0%,100%,0)));
background-image:-webkit-linear-gradient(hsla(0,0%,100%,0), hsla(0,0%,100%,0));

The first background-image declaration, using the -webkit-gradient function, is what will actually work in Safari on iOS today. The second declaration using -webkit-linear-gradient is there for future compatibility; WebKit has recently updated its gradient syntax to match the W3C specification. These syntax changes are in nightly builds and will make it into live versions of Safari and Chrome sometime soon, and you want your CSS to be prepared.

Most of this is not new information—it’s almost all in Trent’s article and comments and the Stack Overflow page. But I wanted to put it all together in one place, clearly explained, for easy reference. Hope it helps you out!

*I don’t actually know that these are true bugs. But they sure seem like bugs to me, and in any case, they certainly need some working around!

Related Posts:

• Media queries presentation at indieconf
• Essential considerations for crafting quality media queries
• A few links: CSS and accessibility
• There’s already a book on responsive web design. Want to win it?
• Free samples of Stunning CSS3

From a technical standpoint, creating liquid designs with media queries is not that complicated, in theory. But doing so requires a sometimes huge shift in mindset and design process, and this is where brief online articles on the topic fall a little short, simply due to the nature of their publication medium. What we really need is a whole book on responsive web design, covering all its intricacies. Ethan Marcotte is working on one, and I can’t wait to get my hands on it when it comes out later this year.

But it turns out that there’s already a book on responsive web design. OK, technically, it’s more like 1.2 books. My first book, Flexible Web Design: Creating Liquid and Elastic Layouts with CSS, is the only book out there that’s entirely devoted to designing and building robust and attractive web sites that adapt to the user’s viewing preferences. It includes not only detailed instructions on how to create the CSS for the layouts, but also how to make the images within them flexible and how to design them from the comp stage with flexibility baked in. All you need to add to any of the layouts you learn about in Flexible Web Design to make them “responsive” is media queries—and I cover those fully in chapter 6 of my new book Stunning CSS3: A Project-based Guide to the Latest in CSS. Put them together, and you have a detailed, comprehensive guide on how to create awesome responsive web designs.

I want everyone to start making responsive web designs, so I want to give away a bundle of both my books. Actually, I want to give away two bundles. So two people will get a copy each of Flexible Web Design and Stunning CSS3.

To win, I’m not going to ask you to follow me on Twitter (though I would really like it if you would) and retweet some canned message about this giveaway (though you’re certainly welcome to tweet about this). All you have to do to win my books is leave a comment on this post. Any comment will do, though I’d love to hear your thoughts on flexible design, media queries, CSS3, or anything relevant to the work we all do.

I’ll pick two commenters at random on Saturday, February 26, at 8am Eastern US time. Good luck!

In the meantime, you can learn more about my books and download free samples at their respective web sites: Flexible Web Design: Creating Liquid and Elastic Layouts with CSS and Stunning CSS3: A Project-based Guide to the Latest in CSS.

Update 2/28/11:

The winners, picked with a random number generator, are Chris Hawkins (comment 16) and Todd C (comment 33). Congrats guys! I’ll be in touch about sending your books.

Related Posts:

• Media queries presentation at indieconf
• Free samples of Stunning CSS3
• Examples of flexible layouts with CSS3 media queries
• Announcing my new book, Stunning CSS3
• Essential considerations for crafting quality media queries

Chapter 2 is titled “Speech Bubbles” and it teaches you exactly that: how to make speech bubbles with pure CSS and no images. The excerpt covers word-wrap, generated content, border-radius, and HSLA/RGBA for semi-transparent backgrounds. The rest of the chapter covers linear-gradient, box-shadow, text-shadow, and transform.

Around the same time I was writing this chapter, Nicolas Gallagher posted an excellent demo on creating speech bubbles with CSS3 too, which I saw later. It’s definitely worth checking out as well. Great inspiration.

Chapter 6 is titled “Different Screen Size, Different Design” and teaches you how to restyle an entire page layout to work with different screen sizes using media queries and multi-columns. You can see the example site used in chapter 6, as well as other real web sites using responsive layouts, at my blog post “Examples of flexible layouts with CSS3 media queries.”

If these samples whet your appetite, you can also see a brief table of contents, images of some of the book’s pages, and links to related resources. And of course, if you’d like to buy the book, there are links to a number of sources in the sidebar of the Stunning CSS3 site.

Learn away!

Related Posts:

• There’s already a book on responsive web design. Want to win it?
• Announcing my new book, Stunning CSS3
• Media queries presentation at indieconf
• Examples of flexible layouts with CSS3 media queries
• Essential considerations for crafting quality media queries

While creating effective, attractive, flexible layouts that adapt to the user’s screen size has always been possible, media queries add another layer on top of flexible layouts to make them even more adaptable to an even wider range of sizes, allowing you to really fine-tune the experience for even more users. Media queries allow you to selectively feed styles based on the characteristics of the user’s display or device, such as how much width is available in the viewport, whether it’s in portrait or landscape mode, or whether it can display color.

My demonstration of media queries is the fictional Little Pea Bakery site, created for my book Stunning CSS3: A Project-based Guide to the Latest in CSS. Here’s how it looks for most users (shown here at 990 pixels wide):

The "default" layout seen by most users.

It’s a liquid (also known as fluid) layout so it can adapt to the user’s screen size, but the design doesn’t look as good and isn’t as readable when the viewport width is very narrow or very wide. I used media queries to solve this problem. Here’s how the page looks over 1200 pixels wide:

The layout for wide screens (over 1200 pixels) adds a third column.

Using a media query and just a few lines of CSS, I was able to easily turn the horizontal navigation bar into a vertical menu in a new third column. This kept the text line lengths from getting too long and making the overall design look too stretched out.

Going in the opposite direction, here’s what happens to the design under 760 pixels wide:

The layout for narrow screens.

We’re back to two columns, as in the “base” layout, but I’ve made changes to keep the content from appearing too squished and the line lengths getting too short. First, I got rid of the two columns in the introductory text. I also moved the three featured product boxes from sitting side-by-side to stacking on top of each other, moving the icon for each one from the top of the product box to the left side.

A third media query improves the design on small mobile screens, seen here at 480 pixels and 320 pixels:

The layout for very small mobile screens uses only one column.

The design is now a single column. The main page heading and introductory text are smaller, as are the product icons.

To see all these changes in action, view the page yourself and resize the browser window. To see how it was done, check out the CSS embedded in the head of the page. You can learn the full details, of course, by reading Chapter 6 of Stunning CSS3.

For more examples of flexible layouts that use media queries to further enhance the site’s adaptability, dubbed “responsive web design” by Ethan Marcotte, see the following sites. Small screenshots don’t do them justice, so be sure to click through to the sites and resize your browser window back and forth to get the full effect.

• Hicksdesign
• UX London
• St. Paul’s School
• CSS-Tricks
• Yiibu
• Sick Designer
• Ethan Marcotte
• SimpleBits
• Science Hack Day
• Salter Cane
• Huffduffer
• Adactio
• mindgarden
• dConstruct 2010
• edgeofmyseat.com
• Daniel T Ott

All of these sites use liquid layouts, but that’s not a requirement for using media queries. It’s also possible to use media queries to essentially create multiple fixed-width layouts that can be switched between on the fly. A few sites that do this are:

• Simon Collison
• Andy Croll
• Ed Merritt
• Ten by twenty
• iA
• Less Framework

Know of any other great uses of media queries in the wild? Please share them in the comments!

Update 1/25/11:

I’ve learned about a few other resources for media queries/responsive layout inspiration:

• Media Queries gallery
• Web round up #11: The best responsive web design examples and resources
• Responsive Web Design: What It Is and How To Use It

Also, I’m bookmarking sites that I find to be nice examples of media queries on Delicious.

Related Posts:

• Media queries presentation at indieconf
• Essential considerations for crafting quality media queries
• There’s already a book on responsive web design. Want to win it?
• The liquid web site motherload
• Why browser zoom shouldn’t kill flexible layouts

You can view the slides on SlideShare, or download the slides here:

Designing with CSS3 Effectively & Efficiently (PDF, 3.3 mb)

Here are several links to related resources that I couldn’t put in the slides but which you might find useful.

Beginner CSS3 Articles

• Start Using CSS3 Today: Techniques and Tutorials
• Modern CSS Layouts: The Essential Characteristics
• Modern CSS Layouts, Part 2: The Essential Techniques
• Prefix or Posthack

Benefits of CSS3

• CSS3 and Veer navigation
• How to: Get CSS3 box-shadow and border-radius accepted as a viable option at your workplace

Media Queries

• A tale of two viewports – part two
• The viewport metatag (Mobile web part 1)
• The orientation media query
• Detecting device size & orientation in CSS
• Designing for the Retina Display (326ppi)
• Protofluid
• css3-mediaqueries-js
• Dreamweaver CS5 media queries

Flexible Layouts

• 70+ essential resources for creating liquid and elastic layouts
• Flexible Web Design: Creating Liquid and Elastic Layouts with CSS

Performance

• The performance business pitch
• Using site speed in web search ranking
• Bing and Google Agree: Slow Pages Lose Users

Finally, if you’re interested in learning more about my book, Stunning CSS3: A Project-based Guide to the Latest in CSS, head on over to www.stunningcss3.com. That’s where the example files for the media query site I showed during my presentation will eventually be hosted. For now, check out the CSS used on the site to see a wide variety of CSS3 techniques in use.

Related Posts:

• Web Directions USA slides and resources
• Media queries presentation at indieconf
• Highly Maintainable, Efficient, and Optimized CSS
• CSS Summit 2010 slides and resources
• ConvergeSE 2010 and upcoming conferences

You can view the slides on SlideShare, or download the slides here:

Effective & Efficient Design with CSS3 (PDF, 2.9 mb)

Here are several links to related resources that I couldn’t put in the slides but which you might find useful.

Beginner CSS3 Articles

• Start Using CSS3 Today: Techniques and Tutorials
• Modern CSS Layouts: The Essential Characteristics
• Modern CSS Layouts, Part 2: The Essential Techniques
• Prefix or Posthack

Benefits of CSS3

• CSS3 and Veer navigation
• How to: Get CSS3 box-shadow and border-radius accepted as a viable option at your workplace

Media Queries

• A tale of two viewports – part two
• The viewport metatag (Mobile web part 1)
• The orientation media query
• Detecting device size & orientation in CSS
• Designing for the Retina Display (326ppi)
• Protofluid

Flexible Layouts

• 70+ essential resources for creating liquid and elastic layouts
• Flexible Web Design: Creating Liquid and Elastic Layouts with CSS

Finally, if you’re interested in learning more about my book, Stunning CSS3: A Project-based Guide to the Latest in CSS, head on over to www.stunningcss3.com. That’s where the example files for the media query site I showed during my presentation will eventually be hosted. For now, check out the CSS used on the site to see a wide variety of CSS3 techniques in use.

Related Posts:

• Adobe MAX slides and resources
• Media queries presentation at indieconf
• Highly Maintainable, Efficient, and Optimized CSS
• CSS Summit 2010 slides and resources
• ConvergeSE 2010 and upcoming conferences