How I Organize My Sass

I work on many websites and often have to jump between them for changes and updates. Keeping things organized is super helpful for finding things quickly. Everyone’s structure is a bit different, but perhaps these notes could help.

What is Sass?

Sass is a CSS pre-processor that turns individual SCSS (Sassy CSS) files into a CSS file used to style a website. SCSS syntax adds some features that help with development like variables, mixins and helpers like darken() for colors. These features make writing and updating CSS a lot easier since things can be reused or changed in one place to make updates everywhere else.

Instead of writing something like in CSS:

.my-parent a { color: blue; }
.my-parent a:hover { color: lightBlue; }

In SASS it’s more structured and easier to read:

$primary_color: blue;
.my-parent {
  a {
    color: $primary_color;
    &:hover {
      color: lighten($primary_color, 20%);
    }
  }
}

May not look easier in this example, but when you’ve got a ton of CSS to manage, this logical structure makes the most sense.

How I Keep Things Tidy

Any site I build will use a CSS framework like Bootstrap, Foundation or Bulma. The framework does most of the heavy lifting, but I don’t want my site looking like any other Bootstrap or Foundation site, so there’s a lot of additional styles needed.

As outlined in my blog post Class Naming, it’s important to name your objects. There are usually some global elements and other section specific elements like a blade or widget. If I name a blade something like “image-slider”, there’ll be a corresponding _image-slider.scss file (or component) that defines that element’s style. This makes things really easy to find when updates are needed.

Folder Structure

CSS stands for “Cascading Style Sheets”. Styles cascade, meaning styles affect child elements, and whichever style is first can be modified or appended to elsewhere. When the compiler creates the CSS file with a .map file or inline mapping, the browser inspector can even point to a specific .scss file, which makes for easy debugging.

With this, and the naming convention in mind, I use the following structure for my SCSS files:

• config – mixins, typography, colors and other variables
• objects – forms, buttons, images
• base – global, header and footer
• utilities – third party things like a javascript slider’s theme
• components – files that match an element’s class name or section

Loaded in this order in the main SCSS file, I can use variables defined in the config in my form object. The form styles can be appended to or overwritten in base or components. A third party utility can have a unique look in a specific blade set in components.

The way config files are structured and what they include would depend on the CSS framework you’re using.

For example, Bulma has some specific color variable names with a “!default”, meaning use theirs if it’s not specified elsewhere. If rebuilding your CSS framework’s styles, they can use the same config files to match your custom styles.

Mixins

Mixins are SASS functions that can make writing CSS a lot easier. For example, I could have a breakpoint mixin that uses the breakpoint variables to write my @media queries. Some may have conditionals that alter the generated CSS output with passed-in values, and others may be as simple as adding all the browser specific -webkit*, -moz*, etc. stuff.

Which mixins you use are up to you, I find them handy to reduce the amount of CSS I have to rewrite. Reusing common mixins between websites helps create the my way for writing CSS.

Variables and mixins are just a few of the things that make SASS great.

Variables

Things like colors, transitions, fonts and other values should be defined as variables. Then if you want to change all blues into greens later, they can easily be done in your config/_colors.scss file. This also helps keep things consistent so that one instance of a color doesn’t accidentally be a slightly different version of that color when pulling rgb or hex codes from a design file.

For typography, I find it’s best to keep it all within a single location. This typography sass file would include things like font families, sizes and all variations of the different font styles used in the design. Ideally, there’s no font style overrides elsewhere and all typography settings are managed in one place, including potentially smaller mobile instances. A clean design file that adheres to it’s own style guide really helps with that.

Compiler

If working locally, the easiest way to compile your sass is with the Sass CLI. I use the following, which will watch for changes and recompile on the fly.

sass watch css/scss/stylesheet.scss:css/stylesheet.css --style compressed

When working remotely when I don’t have SSH access or the server doesn’t have the necessary tools, there are online compilers like the WP-SCSS – WordPress plugin for WordPress.