Determining breakpoints for a responsive design
We present an exclusive excerpt from Tim Kadlec’s book, Implementing Responsive Design, on adopting a future-friendly approach that determines breakpoints according to content as opposed to device.
This is an edited excerpt from Chapter 3 of Implementing Responsive Design, published by Peachpit Press, which went on sale last week. The conventional method of determining breakpoints is to use some fairly standard widths: 320px (where the iPhone and several other mobile devices land on the spectrum), 768px (iPad), and 1024px. There’s a problem with relying on these “default” breakpoints, however.
When you start to define breakpoints entirely by the resolutions of common devices, you run the risk of developing specifically for those widths and ignoring the in-between (case in point, rotate the iPhone to landscape and you’ve just introduced a 480px width). It’s also not a particularly future-friendly approach. What’s popular today may not be popular tomorrow. When the next hot device emerges, you’ll be forced to add another breakpoint just to keep up. It’s a losing battle.
Follow the content
A better approach is to let the content dictate where your breakpoints occur, and how many of them you need. Start resizing your browser window and see where there’s room for improvement.
By allowing the content to guide you, you’re further decoupling your layout from a specific resolution. You’re letting the flow of the page dictate when the layout needs adjusting—a wise and future-friendly move.
To identify your breakpoints, you can reduce the window of your browser to around 300px (assuming your browser lets you go that far) and then slowly bring up the size of the window until things start to look like they need a touch up.
By around 600px, the images in the “More in Football” section start to get a little obnoxious. Introducing a media query here to float those stories to the side, as they were in Chapter 2, “Fluid Layouts,” probably makes sense:
Around 860px, all the aside content starts to feel spaced out. The window is still too narrow to put the aside off to the right, so instead, float the aside sections so they line up in rows of two:
At this breakpoint, it looks like the navigation items could be floated once again, instead of being stacked on top of each other (see below). These styles are in the commented out CSS, so we’ll grab them and place them in the media query. We’ll also remove the border on the navigation items:
Finally, it looks like the aside can be brought back up and to the right around 940px. The sections in the aside will also need to be told to not float, and to take up the full width once again:
At this point, the layout at 940px or wider looks a lot like it did at the end of Chapter 2, “Fluid Layouts”.
Enhancing for larger screens
Making the browser window even wider reveals that it’s not long before the line length for the article starts to be hard to read. Many sites implement a max-width here to limit just how far the browser window can be resized, or bump the font size to improve the line length.
Instead of capping the width of the page just yet, let’s make use of CSS3 multi- column layouts.
The multi-column layout module lets you tell the browser to display the content in several columns as needed. Support isn’t too bad: Opera, Firefox, Internet Explorer 10 and WebKit all support it. Just be sure to use the correct prefixes in the case of Firefox and WebKit. No prefix is necessary for Opera or Internet Explorer. Since this is a nice feature to have, but not essential to the site, we can progressively enhance the experience for these browsers:
Lines 3–5 tell the browser how many columns it should use to display the article. Lines 6–7 tell the browser to insert a 1.5em gap (24px) between the columns. Finally, lines 9–11 tell the browser to include a 1px, light gray dotted line in that gap to provide a little more visual separation (see pic below).
The line length is now much better, but the page could still benefit from some separation between the article and the author information. The picture could use a little more distance from the content as well:
With the border in place around the image and above the section, and the addition of the extra padding, the design is once again looking pretty sharp.
Using ems for more flexible media queries
People browse the Web with their browsers set to different zoom factors. Someone who has difficulty seeing may find that the majority of sites have a font size that is difficult to read, so he may set his preferences to zoom in by default.
When people use different zoom factors, the font size increases (or decreases). In Firefox and Opera, this isn’t an issue; pixel-based media queries are recalculated and applied according to the zoom factor. On other browsers, however, our perfectly placed pixel breakpoints fail us. Suddenly things start to float in awkward ways and our ideal line length is mercilessly thrown out the window. This same issue arises when, as we discussed in Chapter 2, “Fluid Layouts,” a device uses a different default font size. For example, the Kindle’s 26px sized fonts will wreak havoc on pixel-based media queries. We can combat these issues and make our site even more flexible by converting the breakpoints to ems.
As we also discussed in Chapter 2, converting pixel-based measurements to ems is as simple as dividing the target (the breakpoint) by the context (in this case, 16px, the body font size):
With the media queries now set using ems, even if the site is zoomed in a few levels, the media queries will kick in, ensuring that the layout remains optimised.
Using media queries based on em units is another way of embracing the flexibility and unpredictability of the web. It puts the user in control of the experience, and allows the content to dictate the layout.