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.
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:
(example-1.scss)
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.
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:
- If you're using a breakpoint only within one file, define it at the top of that file.
- 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.
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.
Solid post, nicely done!