CSS precompilers are all the rage these days. The basic idea is that you can build more maintainable stylesheets by taking concepts from programming like variables, mixins, and functions. A processor watches your source and builds CSS files based on changes in the directory.
SASS is one of the two most popular CSS precompilers (along with LESS). If you’re not already familiar with the language, it will be important to familiarize yourself with its capabilities before reading through this blog post. There are great guides available that cover how to get started at The SASS Way and A List Apart.
After you’ve written (and come back to) code on projects, you will start to see the 30,000-foot view of how SASS can help code be maintainable. In this post, we will focus on a few rules regarding how to build more maintainable CSS through SASS.
Project Structure in SASS
Thinking about how we use SASS all starts with how we structure our projects. John W. Long at The SASS Way recently profiled a great way of doing this:
project/
..css
.....main.css
..stylesheets/
....modules/
......_mixins.scss
....partials/
......_layout.scss
....vendor/
......_bootstrap.scss
....main.scss
In the project directory, we’ll have two CSS related directories: stylesheets and css. The first will contain our working SASS files and the second our compiled CSS. Inside stylesheets will be three other directories:
/modules/: For SASS code that doesn’t actually output to our compiled CSS like mixins, partials, and variables/partials/: Where most of your CSS will be constructed. It’s a good idea to break your stylesheets into functional pieces. We’ll cover this in a discussion of SMACSS./vendor/: Any CSS that is prepackaged should live in here. At Credera, we’re fans of Bootstrap, and this is where we will put those stylesheets.
The main.scss file will do the @import for all the files inside the three directories.
Using Bootstrap in SASS
Bootstrap is a fantastic framework on which to build many sites. The goal is not to keep the stock UI elements, but to extend them to match your visual style. Unfortunately, it’s not maintained natively in SASS, but Long maintains a port from LESS to SASS on Github.
The best way to start is to download Long’s files and drop them into the vendor directory. The bootstrap.scss and responsive.scss should compile into their own .css files in the css directory.
If you’ve used Bootstrap previously, you’ll be well on your way to building your project at this point. However, don’t forget that SASS also means extra features on top of CSS. Luckily, Long has included some very useful files in his port that you should dig into further:
_variables.scss: Ever get frustrated that everything in Bootstrap is the default blue/black/white? Instead of setting those in a global partial file, make the changes in here. Want to get rid of all the blue links? Just update$linkColorand$linkColorHoverand watch the changes across the whole site_mixins.scss: Also included are a set of mixins that can do a lot for you
SMACSS & Object-Oriented CSS: The Real Secret to Maintainable CSS
Any developer that has updated a user interface written by someone else will understand the spaghetti code that becomes a fight for preference rules to properly style elements. In CSS, it’s too easy to break the first rule of development – don’t repeat yourself, but SASS can help that.
Our workflow starts with Jonathan Snook’s book, Scalable and Modular Architecture for CSS or SMACSS (pronounced Smacks) for short. The important chapters are available for free on his site. The key rules are included in chapters 2-9.
What’s important to understand are the five categories of CSS rules:
Base Rules
Layout Rules
Module (or style) Rules
State Rules
Theme Rules
Understanding these categorizations helps define a new workflow for writing front-end code. Each level builds on top of the last and we should write our front-end code in this order.
As we walk through this example, you can follow along using the source files available on Github.
I like to start with a _layout.scss file in my partials directory and focus on getting things where they need to be on the page, regardless of how they look.
We’ll start with an example Photoshop comp:
Figure 1 – Our example Photoshop comp
The first step is to build a layout that applies no visual style (Figure 2). The goal is to get things where they need to be on the page without worrying about backgrounds, drop shadows, and colors.
Figure 2 – Step 1 of building our CSS, applying our layout
This helps us to achieve the first rule of Object-Oriented CSS, which is separating structure from skin. By having a set of structure/layout rules, we can reuse those across the entire site without repeating the style declarations like margins and easily update them later.
Next, we add our skin styles as separate classes, focusing on making everything pixel perfect. A div might have multiple classes applied to it: <div class="layout style1 state1">. Just keep in mind the principle of not repeating yourself. If a visual style gets used in multiple places, consider the following: 1) making it a single reusable style or 2) applying it as a mixin. The goal is to change it once and have it update everywhere.
Naming Classes for Maintainability
Naming your classes is always a big debate. One rule to keep in mind for long-term maintainability is to name your classes based on what they do, not what they are. For example, instead of naming an alert .message-red, name it .message-alert. That way when your visual design changes and it goes from red to orange, your class names continue to make sense.
Wrapping Up
Creating precompilers for CSS was a brilliant move. By shifting the compatibility to the developer tools rather than the browser, provides new features for CSS that lead to more maintainable code and we can use it in 100% of projects today. No IE6 style compatibility issues here.
I’ve posted a sample project template on Github that incorporates Long’s SASS Bootstrap template and Compass, and can serve as a base for any new project.
SASS allows us to be more granular and organized with our CSS, but still compile it to be something optimized for file size. We just have to keep a few simple rules in mind as we move forward.
If you’ve had experience building maintainable sites in SASS and have any comments, please share those with us below.