One of the more important questions you’ll have to answer in a responsive design is where to set breakpoints. Originally designers chose the dimensions of popular devices as a good place to add them. If the iPad is 768px × 1024px then 768px and 1024px might make for good breakpoints or so the thought went.
Most people who design responsively realize this isn’t a good way to set breakpoints. Aside from ems being a better option than px, the point of responsive design is that we can’t know the canvas in which our designs will be viewed. Why then would we choose breakpoints based on popular device sizes.
A couple of years ago Mark Boulton offered that our breakpoints should come from the needs of our content.
Start designing from the content out, rather than the canvas in.
In addition to setting breakpoints based on the needs of content designers have been suggesting less as opposed to more where breakpoints are concerned. Three recent posts on the topic suggest the opposite.
I’ve been suggesting fewer breakpoints myself, but have noticed in my own practice that I’ve started using more for the very reasons argued in the posts above. I thought I’d share why.
I find there are 3 different types of changes that end up requiring breakpoints.
- Major layout changes — usually involving a change in the number of columns
- Partial layout changes — a column change isn’t needed, but an element like navigation needs significant changes to work in a reduced or enlarged space
- Minor tweaks — small changes like an adjustment in padding or font-size
Major Layout Breakpoints
These are what we’ve all been thinking are breakpoints since the start of responsive design. Last March Luke Wroblewski spent some time looking through the responsive designs collected at the Media Queries website to categorize the high level patterns designers were using.
These high level pattern changes require a major layout breakpoint
These high level pattern changes require a major layout breakpoint. They’re changes that almost always occur because a column in the layout is removed or added. They don’t necessarily need a lot of css to pull off, but the layout itself generally undergoes a large wholesale change.
These are the breakpoints that designers have been suggesting should be held to a minimum. More than likely you’d only need these when changing the number of columns in the layout. By columns I don’t specifically mean grid columns, but columns in the sense of main content, primary sidebar, secondary sidebar.
Major layout breakpoints are where you drop the sidebar below the main content or move it off screen. It might be where information meant as an aside in its own column gets absorbed into another column. It’s where the large blocks of your design need to move around.
Partial Layout Breakpoints
These get grouped with major layout changes, but I think there’s a difference. These kind of changes don’t require your entire layout to change, but rather a significant change to something within the big layout boxes.
Navigation is a good example.You might have a wide horizontal navigation bar that becomes cramped or too open as browser width changes. You might reach points where the overall number of columns in the layout still works, but the navigation needs some significant changes.
Perhaps a single row of links needs to become multiple rows. Maybe a vertical menu would work better than a horizontal one. The change is something that requires more than a few tweaks, but not a wholesale change to the entire layout.
Many times these changes occur at the same point where the entire layout needs a change and so they naturally get grouped together. However, there are times when only the element group needs a change and not the overall layout.
These points, especially when separate from the wholesale layout breakpoints, are even less frequent. Again most of the time they’ll be absorbed in the major layout changes and often the flexible in-between state is enough to handle the changes. Sometimes an additional breakpoint is needed to handle the changes.
Tweakpoints
These are the points most of us failed to consider initially. A flexible layout is great and can handle most of the in-between breakpoint changes, but there are times when an adjustment is needed or at least desired.
For me these tend to be small changes in spacing. It might be a bump in padding by a percent or quarter of an em. Maybe it’s a small change in the positioning of element. These are the px perfect changes designers like to make. Sometimes it’s simply a change in font-size or font related properties like line-height.
Tweakpoints are the minor adjustments we make because something doesn’t quite look right and they tend to be more frequent than the first two categories.
I have a hunch that many of these are less necessary than we think and that some are the magic numbers Harry Roberts recently argued against.
Perhaps these tweakpoints aren’t all unnecessary, though I’ve certainly noticed myself adding styles in tweakpoints solely to push an element left or right or up or down. And I’ll admit much of the time it’s to save the effort of figuring out why it needed that adjustment in the first place.
I admit to a bit of laziness in using tweakpoints, though I don’t think all things placed in tweakpoints are a result of laziness. Sometimes a design needs a few tweaks at certain points.
Where do Breakpoints Belong in Your Code
With more breakpoints where is it best to add them in your code? Common practice has been to place all your media queries at the end of your stylesheet. When you only have a few breakpoints this is workable, though even with only a few I’ve found it can be difficult to keep track of things.
Early on I tried adding media queries directly after the css they impact. If my navigation needed a change there would be a media query directly after the group of navigation styles. My sense was this was the right approach, but I had a hard time making it work for me in practice.
It was easy to accidentally overwrite something in a media query with code that came after in the stylesheet.
That changes with css preprocessors. You can write your media queries inline and the preprocessor will package them all together and drop them at the end of the compiled stylesheet.
While I haven’t yet changed my practice to include inline media queries, I suspect it’ll eventually be the common and accepted practice to include them inline.
Summary
Even though responsive design has been with us a couple of years, we’re still sorting out a few things. Media queries and how and when to set breakpoints are certainly among those things.
Early on we aligned breakpoints with common device dimensions. Then we realized they were better set based on the content and we called for fewer breakpoints only when wholesale layout changes were required. Practice suggests more breakpoints are needed.
At the very least there are 2 distinct types of breakpoints, those for major changes and those for minor ones. I think there’s a 3rd group in between where the change isn’t as major as changing the entire layout, but is significantly more than a tweak. A point in the middle where the internals of a large block in your design need changes, but not all blocks need to be rearranged.
How about you? If you’ve been working with responsive design, where have you been setting breakpoints? Do you find you only use a couple of media queries for the major changes or are you including tweakpoints as well? Are you noticing you write breakpoints in between the major and minor changes?
Download a free sample from my book, Design Fundamentals.
So far I have been using very few breakpoints (3 or so), and twiddling the design to work around those. This isn’t really a ‘content out’ approach.
This article with all its cross-referencing is good food for thought.
PS: The link to ‘magic numbers’ by Harry Roberts is dead. You seem to have used ‘hrref’ instead of ‘href’.
That’s how I started. I’d set up default styles for a phone and add breakpoints for tablet in portrait, one for tablet in landscape, and one for a desktop.
Then I would see myself adding breakpoints in between to tweak a few things and the more I’ve thought about it, what I’m doing is what I point out in this post. I won’t be surprised if it all changes again before long.
Thanks for noticing the extra ‘r’ in the link. It should be fixed.
Lovin the new blog design, it has been a while since I stopped by. Everything is so clean and readable.
I see the two main breakpoint types, major and minor, aligning with two of the style groups in SMACSS, layouts and modules.
Breakpoints applied to your layout styles are the major breakpoints, layouts applied to your modules are the minor breakpoints.
I have used breakpoints like the third method you mention, making small changes to font-size or line heights as well. I think the point about magic numbers is spot on. I tend to lean towards using fewer breakpoints and relying on the fluidness of the elements working in the in-between states.
I also have been putting my media queries at the end of my stylesheet, though am starting to place them right after the module or layout style they are changing.
Thanks Brett. I forget some people have probably never seen the new design, even though it’s been up for awhile. If you normally read in a feed reader you never see the design. Clean and readable were definite goals.
I see the SMACSS comparison. I think the “module” breakpoints would need to affect the layout of the module or at least something major with it. I wouldn’t consider this a tweak to the module, but otherwise I agree and I’m guessing you’re fine with what I just said.
I have a feeling the tweaks are things we don’t need to do most of the time, but since we can and it’s easy…
Same here with media queries. I’m just starting to place them right after what they change.
I’ve been working with responsive design a lot more lately. I’ve tried multiple approaches on where to put media queries in my CSS and I haven’t come up with a solution that I really feel great about. Most of the changes occur at 1 or 2 layout break points so I put them together at the end. I’m finding using em’s and percentages really help out with the phases in between the major and partial layout break points. I would like to use those fluid scaling methods even more. I think it will just take some time though for trends in web design to move more toward designs that scale more easily.
I think in some cases the media query has to end up at the end, because your non media query css could potentially overwrite some things.
If you’re careful or if you use a preprocessor you can place it right after whatever code it affects. The preprocessor can move it all to the end for you.
Absolutely. If you use ems and % it takes care of a lot. I’ve switched to them for everything. ems for vertical and % for horizontal. I know some px get in there or there, but for the most part I only use relative measurements now.
I got started with responsive design by having a look at my metrics and basing my breakpoints on the most common devices that accessed my site. In that design, there were only a few major layout breaks (iPhone, iPad, and Desktop).
I’ve been experimenting with Flexbox though. Eric Meyer’s talk at the W3Conf got me especially excited about that and the CSS grid spec, even though he only showed about five minutes of it. I feel like responsive design is going to take a huge leap with these modules being built especially for flexible layout.
As for media queries, since I use Sass, I’ve been setting up mixins for breakpoints as I need them. The body of the mixins simply contain @content. And then I just include where needed and add my rules.
I’m always trying new approaches, however, because I’m kind of a geek about efficiency and maintainable projects.
The last thing I’ll say: whether you’re using device breakpoints or building from content out, setting arbitrary widths will just put an unprepared designer in a world of pain. Appropriate breakpoints are informed by the design. Always.
I did something similar at first. It was a combination of popular devices and ones I saw in my analytics. I’d be lying if I said some of those same values aren’t featured prominently as breakpoints still, but I don’t set out to choose them because of the device.
I’m excited about flexbox too. I’m working on an article about it for Adobe now. It makes a few things so easy and I think it’s getting close to be ready for production.
I’m still writing media queries at the end of Sass files, though I’m ready to drop them in right after the css they affect. Mentioning it in this post was as much a reminder for me as for anyone reading.
Great close to your comment. I completely agree about arbitrary widths. The design should definitely be informed by the content.
What do you think about ‘local’ (A breakpoint that only apply on specific page) breakpoint?
I tested this website responsiveness and found that the h1 element on this article page is the one that changed on certain breakpoint.