Flexible layouts work well to a point, but there comes a time when we need a more drastic change than simply allowing design elements to expand and contract. There comes a point where we need the ability to make larger changes in how elements flow within a design. Enter media queries. Now with official W3C goodness.
If you know your responsive design basics there are 3 ingredients to a responsive site.

Flexible layout

Flexible media

Media queries

Over the last couple of months I’ve been talking a lot about the first 2. It’s finally time to talk about the 3rd. The basics are easy and I’ve covered them before. However there are some decisions you need to make when using media queries, specifically how and where to set your breakpoints.

Media Query Basics

In some ways media queries are similar to the browser detection we did years ago. The major exception is they work better and are simple to implement. Instead of complicated Javascript we now have a simple css declaration to test various conditions.

You’ve likely seen this before, but in case you haven’t the above is checking to see if the browser width is at least 768px wide and if it is the css inside is applied.

While we have a few things we can test for, we’re still somewhat limited and most media queries tend to be a test against min or max width. The CSS4 editor’s draft adds a few things and I’m sure in time the list will continue to grow.

Setting Breakpoints

Where to set breakpoints is the big question with media queries. First thoughts are usually to choose breakpoints based on the size of popular devices. For example since the iPad has a screen width of either 768px or 1024px you’d set a breakpoint at each. This doesn’t make sense. The iPad, while popular is but one device. There are countless others and we may not be sure what device is being used to access our content.

If we’re trying to set breakpoints based on all the devices out there, it defeats the whole point of why we’re designing responsively in the first place.

Min or Max Width

As I said above we’ve mostly been testing against the width of the device being used. Assuming for a moment that’s what we test against, we have 2 choices to start. Should we test against a min-width or against a max-width?

The first fits better with a mobile first thought process. You would develop default css rules for your design on a smaller device and add media queries and css as the device gets larger and your design needs to adapt. With max-width the situation is reversed and you’d likely develop for a wider screen first, working your way back to mobile.

Either process can work, though I prefer the former starting on the mobile device and working up. You can also set both a min-width and a max-width on any media query to add rules over a range of widths.

The content of a box dictates its width. It is the minimum width of adjacent containers that create break points.

He continues and offers 3 things to keep in mind when making decisions about where to set breakpoints.

The width of a box should be as small or as wide as possible without impairing readability.

The max-width of a box should take into consideration the importance of following boxes. This is because the wider the box, the wider the viewport must be to reveal subsequent boxes.

The goal is not to bring everything above the fold (we don’t want to fill the viewport with clutter).

Much of his post walks through an example of setting breakpoints and I recommended giving it all a read if you haven’t seen it before. The key point is that breakpoints for media queries should be based on when the content needs to change and not because there’s a device out there with a screen of a certain size.

Breakpoints Based on ’em’ Instead of ‘px’

Typically when setting either a min-width or max-width media query, the measurement is ‘px’ based. If the idea is to set breakpoints based on our content, isn’t there a better measurement we can use? Are we tied to the pixel? Nope. There’s nothing stopping us from using em-based media queries.

One of the issues that most of us don’t consider is someone increasing the font size in the browser to zoom in on our layout. Zooming doesn’t trigger a media query, though perhaps it should. When you think about it the reason we set a breakpoint in the first place is because the space our content can occupy is either more or less than it wants to occupy. A similar thing happens when you zoom in or out of a page.

If instead of tying media queries to ‘px’ measurements, we use ’em’, then our layout can adjust to the change in font-size. This further ties our breakpoints to our content. You can see this working in action on a post from Cloud Four Blog The EMs have it: Proportional Media Queries FTW!. Zoom in and out on the page and notice how at certain points the layout changes as though you were resizing your browser.

A single column of text should ideally be about 66 characters per line or roughly 30em. The space available for to hold 30em will be too big, too small, or just right, hence the Goldilocks moniker for this approach.

too much space — you can move from a single to a multi-column layout

too little space — you can drop columns or reduce the outside margin

just right — good for you. there’s nothing to worry about.

Chris’s post goes into more detail and also links to a demo you can check and also contains some boilerplate code you can download. Definitely worth a full read and again it’s setting breakpoints based on the needs of the content, not arbitrary device sizes.

Summary

Media queries are one of the big 3 of responsive design and using them is pretty easy. The big questions are where and how to set breakpoints.

It makes more sense to set breakpoints based on the content as opposed to the device. Content out and not canvas in. I prefer a mobile first thought process and test against min-width, though max-width or both to cover a range of values also works.

While setting breakpoints based on ‘px’ measurements has been common practice, better is to use ’em’ measurements. It alleviates an issue with zooming and is also more closely tied to content instead of device.

Fewer breakpoints will usually be better than more. Design flexibly and add a breakpoint where your layout needs to do something more than expand or contract, usually when your content requires a change in the number of columns being used.

This series has now covered all 3 ingredients of responsive design. Next week I want to look at responsive workflows and some practical thoughts for developing responsively.