Mo' Bears, Mo' Problems: Using Names to Manage Dozens of Breakpoints

Breakpointing with Bears

Earlier this year, Chris Coyier wrote about some conventions for naming breakpoints in Sass. His idea revolves around giving breakpoints names so that you can tell at a glance what size a breakpoint is happening. He uses a Goldilocks analogy for breakpoint names: baby-bear, mama-bear, and papa-bear for small, medium, and large viewport widths respectively. This is great because it lets us put all our style breakpoints in a single place. Also, by keeping our variable names abstract, it keeps us thinking in a device-agnostic way. In the article, Chris advises to avoid using device-centric breakpoint names like “iPad” because they’ll date quickly and set up bad expectations. Good thinking, Chris.

His approach is awesome for site-wide breakpoints but isn’t as suited for lots and lots of different breakpoints on a more granular level. Ben talks about this in his There Is No Breakpoint article. The idea of his article is to add breakpoints that are tailored specifically to the modules of your site and to not worry about snapping your numbers to fit in with the rest of your site’s breakpoints. Less baby-bear, mama-bear, papa-bear. More 23em, 41.4em, 71em, with lots of unique numbers sprinkled in between.

Taking this approach, we’ll likely end up with dozens of unique breakpoints throughout a site. It doesn’t make sense to name every one of these. The name great-great-great-great-grandpa-bear doesn’t quite roll off the tongue. Giving names to all of these breakpoints would be difficult, and frankly, useless. And with names like that, website maintenance would be simply unbearable.

However, that doesn’t mean we can’t or shouldn’t name our breakpoints when we have a lot of them. We can still benefit from keeping related breakpoints in one place. This will let us change a single number that’s reflected in multiple places.

Real-Life Example

Let’s say you’re coding up a website header. At small sizes, your website name is stacked on top of the tagline. When the viewport’s a little bit wider, that tagline floats beside the website name. Let’s say the point at which this split happens is 32em.

So at 32em wide, two things need to happen: first, the website name needs to float to the left; second, the website tagline floats to the right. These two things are happening to two different elements, but they’re happening for the same reason: to put these elements side-by-side. This is the ideal situation to name a breakpoint.

In Chris’ article, he’s applying breakpoints via a Sass mixin. You pass in the name of the breakpoint and a block of content, and it spits out that content scoped to your media query. Again, this is perfect for site-wide breakpoints, but it doesn’t work as well when you’ve got many unique breakpoints. For this reason, I like to keep breakpoints in Sass variables. This way, you can give your variable a nice, meaningful name, then use that variable in a @media declaration or a breakpoint-making mixin such as SB-Media or Breakpoint.

As a convention, it’s useful to prefix the variable name with bp-, in order to denote that the variable contains a length that’s intended to be used as a breakpoint. This lets us see what’s in the variable at a glance and have a good idea of what it’s used for without looking for the definition. I’d suggest you do something similar with all other variables in your styles, too.

I like to name breakpoints after the overall goal that they’re achieving. For example, in this case, we’re splitting up the header, so I might name it something like $bp-header-split or $bp-header-streamline. You could also base it on the module and size combination, like $bp-header-medium, which leaves wiggle room to add a $bp-header-large breakpoint at larger sizes.

Here’s a dead-simple example of what we’ve got:

$bp-header-split: 32em;

header {
  h1 {
    @media (min-width: $bp-header-split){
      float: left;
    }
  }
  h2 {
    @media (min-width: $bp-header-split){
      float: right;
    }
  }
}

With this setup, we’re able to change the point at which the header splits by changing a single number. Now we don’t have to perform a dangerous find & replace operation on the phrase “32em” every time we want to move this breakpoint. Just change the value of the variable.

An Aside on Organization

In real projects, you’re definitely going to have more complex styles than our example. This might make it difficult to know where to define your breakpoints. If you’re splitting up your styles in a modular way, there are two rules you can follow to find breakpoints easily:

1. If you’re using a breakpoint only within one file, define it at the top of that file.

2. If you’re using a breakpoint across multiple files, put it in a general variables file, and import before anything else.

This way, you won’t run into any problems with ordering files, and you’ll be able to find a breakpoint within seconds. Pro tip: you can also follow these rules with all other variables as well as mixins and extends. Boom.

Back to Our Regularly Scheduled Example

Now let’s say you code your way down the page, defaulting to unique breakpoints based on content but using named breakpoints when appropriate. But then you come upon the footer. We have a list of links in the footer that’s stacked at small sizes and displayed inline at larger sizes. The size we want these links to go inline is... wait for it... 32em.

“32em!” you shriek. “That’s the number we used before! Surely these numbers ought to be consolidated into one, easy-to-find, easy-to-manage place! We were just talking about this!” you cry.

Well, not necessarily. While both of these things are happening at the same point, that’s where their similarities end. The “splitting of the header” and the “inlining of the footer” are two different events that are happening independently from each other. If one were to change, the other shouldn’t necessarily change. If you were to give a name to this breakpoint, what would you call it? $bp-header-split-and-footer-inline? Or maybe $bp-32em? No, thank you. Here’s a rule of thumb: if a breakpoint is really hard to name, don’t bother naming it.

For those of you who like solid code to play with, here’s a CodePen so you can see how I’d handle the header/footer breakpoints.

Bearable Breakpoints

Let’s recap.

1. It’s nice to use breakpoints where individual pieces of your website break down. Don’t feel like you have to squeeze your values into site-wide breakpoints.

2. When you find yourself writing breakpoints that are closely related to one another, group them into a variable with a meaningful name.

3. Finally, just because two breakpoints are happening at the same place, it doesn’t mean the two values should come from the same variable.

Following these guidelines will help you write more maintainable styles. You’ll know you did it right if you find yourself fixing issues with single-line commits. And that feels just right.