An experienced backpacker will tell you, the way you organize your bag for a trip is just as important as the shoes you wear. As I was writing some styles the other day, I realized how much organizing Sass is like organizing my backpack.
When I pack up for a big ole hike, I always put heavy, less frequently needed things that anchor my whole trip into my bag first—things like my sleeping bag, sleeping pad, and hammock. Then, as I move up toward the top of my bag, I pack things that I will need to access more easily and move around—things like clothing layers and cooking utensils, snacks, first aid gear, a compass, and a map.
Let’s Talk Internets
There was a time when vanilla CSS was my go-to. I’d write every little bit by hand. My first round would be a beautiful piece of work that I was always proud of. But when the inevitable revisions came along, and I had to start changing things around, adding classes or sections, things could start to get messy.
It became very hard to keep things organized because of the inflexible nature of writing straight CSS. Then, I’d start to do weird stuff like keep a document open with sections of CSS rules that I found myself repeating often so I could just copy/paste into my master document when needed. Like I said, sustainability nightmare.
Along Came Sass
Until about a year and a half ago, I was unaware of “preprocessors.” Then I heard about Sass and thought to myself, “Why would I use this? I write great CSS.” Then I actually used it. Game changer.
Sass: Syntactically Awesome Style Sheets. Sass puts a whole plethora of tools in your hand. You can now nest your styles rather than writing long strings of class names. It allows for faster, more organized creation of stylesheets through features like mixins and extends.
I could go on and on about how Sass is like the webbing on your backpack for modular packing, but this article assumes you already have a general knowledge of the tool.
High-Level Organization
Here at Sparkbox, we like to create a separate .scss file for each part of the site, using SMACSS-like thinking.
Example: _fonts.scss, _colors.scss, _header.scss, _footer.scss, _blog-listing.scss, _hero.scss
This allows us to break our styles into small, manageable chunks. These files are usually no more than 150 lines. And these files, specifically the ones that have global impact like fonts and colors, are like the tents and sleeping bags. I set them up first, and they’re the base for everything I do from there on out. I won’t need to access them too much once they’re packed in.
It’s worth mentioning that if your stylesheet starts to creep up over 200 lines of code, you may want to consider breaking the file up or refactoring some of your code.
Little Bits
As I write my Sass, I try to follow a structure as I add rules to each element. These little bits will be easy to move around, access, and modify later on—just like the stuff I pack higher up in my bag. For example, you may have a small mixin that changes the background color of any element with a class name .warm, like an extra fleece.
Element to be Styled
header{
Enter Mixins First
@include mixin-name (for text styles)
@include mixin-name (for layout)
@include mixin-name (for color)
If there are no existing mixins for what you need to do, then style your text, layout, and color respectively.
Example:
font-family: Georgia, times, serif;
color: #333;
margin-top: 1rem;
padding-right: 1rem;
background-color: #efefef;
If media queries are part of the equation, I add them next. Read how we use a Sass mixin for media queries here at Sparkbox. This is an exception to my rule on where mixins go.
@include sb-media{
//Add CSS following the same organization as above.*
}
Now you’re ready for any nested styles you may have. Add these following the same rules of organization. We try not to go deeper than two or three levels when nesting our CSS. If you get this far down, it’s probably safe to break up the styles.
.nested-header-style{
@include{}
.rules{}
}
}
Hit the Trail
In my eyes, this technique creates easily scannable, modular, and maintainable Sass files. These are not set rules for anyone, though. Just my practice. I believe any form of organization is better than none.
