3 Types of Breakpoints In Responsive Designs

Posted: 28 Feb 2013 05:30 AM PST

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?

The post 3 Types of Breakpoints In Responsive Designs appeared first on Vanseo Design.