We’ve completely changed the way we write responsive breakpoints here in the studio. Looking back at our former agony, our previous method is practically dark ages material. We’re here to show you a better way.
It’s often written—and possibly accepted as best-practice—that you should separate your media queries by device class. You might have a “small” and a “medium” and a “large” file, for instance, and you include each one in turn, so that you’re including some base CSS files, along with a series of files for each device.
The problem is that, if you are looking for what’s influencing a particular element on the screen, you often have to dig through each of those files. This is because I often define a simple set of rules for the smallest device (phone), and then a series of rules for each larger size. So you might have to look at a lot of files, digging through each, to find your rule.
This. Totally. Sucks.
Enter SASS, about the greatest thing since sliced bread to a web designer like me. It lets you break apart your files in a very clean fashion, put them back together with mixins, and lets you structure your code in a way that’s far clearer than CSS by itself. Not to mention the addition of variables and math, so that instead of writing 40px, you can write something much more clear such as $lovely_margin * 2.
I much prefer to break my files apart by their purpose. I’ll have a basic style.scss file, whose purpose is to load all my other files. I’ll have a styleguide.scss file to set up the colors, fonts, and common dimensions the project should use. There will be a file to set up the grid structure, and I’ll have a file for each of the site’s sections.
There will also be a mixin.scss file, which has common functions and fixes we use on a lot of projects. For this, I’ve adapted an incredibly simple mixin for SASS that lets you write all your rules in place.
Based on a mobile-first assumption, this is super simple to use. You simple define your mobile (or most general-case) rule first, then put the specific rules for larger sizes below that. For example:
In this example, it’s very clear to me that we have a rule for a specific page, aimed at a specific item, and that it has a behavior for a phone (400 pixels tall, full width) that is then overridden on tablets (where it gets taller and becomes two-column) and, finally, on desktops (where it’s three column).
No more hunting through five files to find the one rule I’m looking for. They’re all there, in one place, and I can test them all at the same time and get it just right. What took us so long?
