Breakpoint 1.0

Breakpoint Title Card

Don’t feel like reading? Go get it now


About a month ago I was working on a responsive site, and trying to do it right. So instead of setting break points to match device dimensions (for phone, tablet, and desktop) I would set break points when my content and design needed them. Taking this kind of control over your responsive design means two things:

  1. You probably have a LOT more media queries
  2. And you lose track of why you used each one.

I needed a system to manage media queries.

As anyone who knows me knows, I’m a huge Sass nerd. Like, huge. So of course I was already trying to manage my breakpoints with my own system of variables and a super-cool mixin. Well that mixin was quickly growing unweildly, so I knew it was time to make something better.

I started with a few assumptions

  1. Most queries test the min-width feature.
  2. Variables are a good way to manage queries in a growing project.
  3. It’s nice to have a short easy syntax, that would still allow for complex queries when needed.

So I started with the syntax and worked it out from there. Since I wanted something simple I settled on using a mixin called “breakpoint”. That’s easy to remember. And since I’m making some assumptions on common use cases I decided to pass that mixin an argument that could contain just a simple numerical value. So, the simplest and most common use of breakpoint goes like this:

Simple use

1
2
3
4
$breakpoint-medium-width: 500px;
.foo {
  @include breakpoint($breakpoint-medium-width) {...}
}

Which compiles to:

1
@media (min-width: 500px) {.foo {...}}

min/max use

I expanded the syntax to accept numerical pairs, signifying a min/max relationship. The default feature is min/max-width.

1
2
3
4
$breakpoint-medium-not-wide: 500px 700px;
.baz {
  @include breakpoint($breakpoint-medium-not-wide) {...}
}

Which compiles to:

1
@media (min-width: 500px) and (max-width: 700px) {.baz {...}}

Feature / value pairs

I can’t limit this to just one kind of feature test, so if you pass in a feature name and a value it knows what to do.

1
2
3
4
$breakpoint-not-too-wide: max-width 700px;
.wtf {
  @include breakpoint($breakpoint-not-too-wide) {...}
}

Which compiles to:

1
@media (max-width: 700px) {.wtf {...}}

Stack ‘em up

Since I want to be able to create as complex a query as needed you can stack these up in a comma-separated list. You can even use one-sided tests like monochrome

1
2
3
4
$breakpoint-wide-portrait-mono: max-width 700px, orientation portrait, monochrome;
.zztop {
  @include breakpoint($breakpoint-wide-portrait-mono) {...}
}

Which compiles to:

1
@media (max-width: 700px) and (orientation: portrait) and (monochrome) {.zztop {...}}

I use this a lot. All over the place. Giving my breakpoint variable names that make sense keeps me organized, and the syntax makes me faster. Yay!

Collaborate, refine, add features

I told my friends about this, and one in particular practically pounced on it. My good buddy @snugug had been working on another solution to managing media queries and decided that Breakpoint would be a good engine for his syntax as well as the default one. And once he gets his claws in something he doesn’t let go. And that’s awesome, because now I can very happily say that Breakpoint is ready for prime time.

You want configuration options? You got ‘em.

You want to use ems instead of pixels? (You should.) Now Breakpoint can do the calculation for you.

You want to use device-pixel-ratio? (You shouldn’t.) Breakpoint will convert those to resolution for you.

Sam added these features as well as a ton of refinements to the code base. Everyone, thank Sam, OK? He’s pretty rad.

Add a break point at the point where it breaks.

Go get it now!