Skip to content

Instantly share code, notes, and snippets.



Last active Dec 25, 2015
What would you like to do?
A post on how to name media queries, why you'd want to, and the reasoning behind it.
$bp-header-split: 32em;
header {
h1 {
@media (min-width: $bp-header-split){
float: left;
h2 {
@media (min-width: $bp-header-split){
float: right;

Naming Media Queries in a Breakpoint-free World

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 of 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 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 is 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, 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 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:


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 this 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 is 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 of 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.

Let's recap. 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. When you find yourself writing breakpoints that are closely related to one another, group them into a variable with a meaningful name. Finally, just because two breakpoints are happening at the same place, it doesn't mean the two values should come from the same variable.

You'll know you did it right if you find yourself fixing issues with single-line commits.


This comment has been minimized.

Copy link

@zastrow zastrow commented Oct 16, 2013


Nice simple overview, Ethan. I think it gets to the point explains two views and then you do a nice job of explaining your blending of these two approaches.

One suggestion: I think adding in a short mention that these naming conventions are within a CSS preprocessor. While we use preprocessors and probably a lot of people reading this know about or use a CSS preprocessor. But, a quick mention might help those that are still new to preprocessors or are unfamiliar with them.


This comment has been minimized.

Copy link

@tinystride tinystride commented Oct 16, 2013

This is really solid Ethan.

Would it be outside the scope of the article to talk about where to declare these breakpoints? That might fit better in a 'how to organize Sass partials' article—I'm not sure.

I'm thinking of the structure we've used on recent projects:

  • breakpoints used in across more than 1 Sass partial live in general-variables.scss
  • breakpoints only used in 1 Sass partial live at the top of that file.

It's great as-is though!



This comment has been minimized.

Copy link

@asimpson asimpson commented Oct 16, 2013

Solid post, nicely done!


This comment has been minimized.

Copy link

@robtarr robtarr commented Oct 16, 2013

Looks awesome! I just have 2 small things:

  • Chris Coyier
  • I wonder if lots of arbitrary numbers sprinkled in between makes it feel like the chosen values don't mean anything, where in fact they do, they're meaning is simply scoped to what they are applied to instead of the entire site.

This comment has been minimized.

Copy link
Owner Author

@ethanmuller ethanmuller commented Oct 16, 2013

Thanks for the feedback, donut-eaters.


This comment has been minimized.

Copy link

@andyknapp andyknapp commented Dec 19, 2013

So glad I came across this. For a while I've had breakpoint naming anxiety - whenever I'd read an article like the one you mention on CSS-Tricks, I felt like I was just missing something because my breakpoints always seemed arbitrary in comparison. In my opinion, trying to apply a site-wide naming convention takes you further away (consciously or not) from adding breakpoints when the content calls for it.

Thanks for the post!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.