Sass has been around since 2006, and is quite popular. However, since organizing the ATL Sass Meetup a year ago, I’ve met plenty of people who have heard about the language, but aren’t exactly sure where to start. This post is designed not only to help new users get their projects up and running, but it will help more seasoned users shift their sassiness into the fast lane.

What is Sass?

Sass is a stylesheet language that compiles into CSS, adding features like variables, mixins and iteration that do not yet exist in the CSS language. Sass has two syntaxes. (For this post, we’ll be writing in the .scss syntax.)

Installing Sass

Our first step for brand-new users will be to get Sass installed. Open up the command line, and run:

gem install sass

If that fails, try running:

sudo gem install sass

Success? Check the version:

sass -v

Still having trouble? Look here.

Compiling Sass

Now that we’ve got Sass installed, we’ll need to look at how we want to compile our Sass code into CSS.

Sass can be compiled via the command line, or with a desktop application like Codekit, Prepros or Scout.

There are also a number of task runners that will compile your Sass for you like Gulp, Grunt or Broccoli.

For the remainder of this post, we’ll be using Gulp to compile our Sass (and do other CSS related things that will make our lives easier).

We are going to use Gulp to:

• Start our local server
• Watch for changes to our Sass files
• Check for errors
• Compile our Sass
• Add CSS3 vendor prefixes
• Add minification
• Write our CSS file
• Reload the browser

Installing Gulp.js

First, make sure that Node is installed:

node -v

If you need to install Node, you can download it here.

Now install Gulp.js:

npm install -g gulp

If that fails, try using sudo:

sudo npm install -g gulp

Now we are ready to set up a new project.

Download the Template

First, download the starter template. This template contains:

• package.json – a list of npm packages that we will install
• gulpfile.js – a list of tasks that we want Gulp to run for us
• application.scss – our Sass file
• index.html – our hello world web page

Now we just need to install all of the npm packages listed in our package.json file.

In the command line, navigate to the root of the starter template, and run:

npm install

That should have created a node_modules folder with all of the npm packages listed in the package.json file.

We’ve just installed:

• browser-sync – our local server and live reload
• gulp – the task runner
• gulp-autoprefixer – adds CSS3 vendor prefixes
• gulp-minify-css – minifies CSS, using clean-css
• gulp-notify – provides error messages
• gulp-plumber – prevents pipe breaking caused by errors from gulp plugins
• gulp-rename – adds .min to file name
• gulp-sass – compiles our sass

Now we just need to run:

gulp

This will run our default task. This task starts up our server local server, opens the browser and begins watching our Sass file for any changes.

Let’s trigger the styles task by making some edits in the application.scss file.

body {
  background: red;
}

When there is a change in our Sass file, the styles task will:

• check our Sass for errors
• compile our Sass
• add the needed vendor prefixes
• minify our code

Finally, the reload task will reload our browser.

For a look at exactly how this is set up, check out the project’s gulpfile.js. Breaking down the gulpfile.js is outside of the scope of this post, but if you’d like a good tutorial, check out Todd Gandee’s Journey into Gulp post.

Some Additional Gulp Tasks

A few other Gulp tasks that you might consider adding into your build process are:

• gulp-hologram – a living style guide
• gulp-sass-lint – jshint style linting for Sass
• gulp-phantomcss – CSS regression testing

Project Organization with Partials

We’ve got a pretty good build process set up, but instead of having one giant Sass file, lets look at how we can better organize our code using Sass partials.

When Sass compiles, it will create a matching CSS file for any file with a .scss or .sass extension. However, if we prefix our file names with an underscore, Sass will not create a matching CSS file.

So, application.scss will get a matching application.css file, but _my-partial-file.scss will not.

We can use this technique to create an organizational structure for our project. We’ll break our styles up into partial files, and then use @import to bring all of the partial files into the main application.scss file.

// in the application.scss file
@import 'my-partial-file-one';
@import 'my-partial-file-two';
// etc

css-burrito

So, what should our structure look like?

I have written an open source Sass Template called css-burrito that will provide a very scalable Sass structure. In addition, it will automate a few tasks for us like adding and removing partial files.

The template contains three directories and an application.scss file to @import all of the partial files.

libs/
  _library-variable-overrides.scss
  _normalize.scss

global/
  _settings.scss
  _utilities.scss
  _base.scss
  _layout.scss
  _skin.scss
  _typography.scss

modules/
  _modules.scss

application.scss

Libs

The libs directory will house all third-party library code. Add libraries like Bootstrap, Foundation or Bourbon here. By default, this folder contains:

• _library-variable-overrides.scss – override any third party library variables in this file.
• _normalize.scss – Normalize v3.0.2

Global

The global directory is where we will keep all of the utility code that will be used across the entire project. It should be organized as follows:

• _settings.scss – global variables and maps
• _utilities.scss – global placeholders, extends, mixins, functions and utility classes
• _base.scss – global defaults for base level tags like <body> or <p>
• _layout.scss – global layout styles like margin, padding or floats
• _skin.scss – global skin styles like gradients, colors and box-shadows
• _typography.scss – global typography classes

Modules

The modules directory will ultimately contain the majority of the code in your project. You’ll add new modules as needed based on the design. This directory also contains a _modules.scss file, to @import all of the other modules into the application.scss file.

css-burrito Comes with Superpowers!

If you want css-burrito to create files and @import them for you, you’ll need to install it as a global npm package.

npm install -g css-burrito

Once installed, you can quickly add a new instance of the css-burrito template by navigating to the root of the project and running:

burrito -n [folder-name] [file-name] [path-to-sass-directory]

This will create a new instance of the css-burrito template, and a css-burrito-config.json file.

Once the config has been created, you can update the modules directory in a number of ways.

Add new module partials to the modules directory:

burrito -m (file-name[s])

Remove module partials from the modules directory:

burrito -r (file-name[s])

And list the partials in the modules directory:

burrito -l

css-burrito Customization

If you want to rename any of the files or partials, or edit the structure of the template itself, you can make edits to the css-burrito-config.json file. Once the config edits are in place you can generate a customized version of the template by running:

burrito -g

Let’s Put This all Together!

Ok, so now we have an awesome build process set up with Gulp, and we know how we want to organize our files.

Let’s create a new project by downloading the starter template.

The gulpfile.js has been updated to watch our new project.

Sassy Patterns

Now that we’re ready, we can finally begin to write some code!

Lets take a look at some useful patterns.

Sass Maps

I use Sass maps in all of my projects for two reasons. First, it limits the number of global variable names in the project, and second, they can be iterated over with an @each loop.

To get something out of a map, you’ll use the built in map-get() function. This takes two arguments, the name of the map and the key that you want to get out.

$colors: (
  'primary': #bada55,
  'secondary': #c0ffee,
  'tertiary': #de1e7e
);

.thing-that-needs-some-color {
  background: map-get($colors, 'primary');
  color: map-get($colors, 'secondary');
  border: 1px solid map-get($colors, 'tertiary');
}

Play with this gist on SassMeister.

Custom Functions

I am not a big fan of typing map-get() everytime I want to get something out of a map. Instead, I like to create a function for each map to get things out for me.

Let’s create our own custom function to use with the $colors map. This new function uses the built-in Sass function map-has-key(), which takes in a map and a key and returns true or false depending on if the key exists.

When we call the colors function, we pass in a key—in this case, the color that we want to get out. If the key exists, our function will run a map-get() for us. Otherwise, we log a warning and exit out of the function.

$colors: (
  'primary': #bada55,
  'secondary': #c0ffee,
  'tertiary': #de1e7e
);

// grab colors from $colors map
@function color($key) {
  @if map-has-key($colors, $key) {
    @return map-get($colors, $key);
  }
  @warn "Unknown `#{$key}` in $colors.";
  @return null;
}

// lets call the function 3 times
.thing-that-needs-some-color {
  background: color('primary');
  color: color('secondary');
  border: 1px solid color('tertiary');
}

Play with this gist on SassMeister.

@each Loops

Finally, we can iterate over maps using an @each loop. Here, we are looping through the colors map, getting the $color-name and $color-hex, and creating a ruleset with that data. We need to use interpolation to add the $color-name.

$colors: (
  'primary': #bada55,
  'secondary': #c0ffee,
  'tertiary': #de1e7e
);

// loop through the colors map,
// get the key and value,
// and create a ruleset with the data
@each $key, $value in $colors {
  .t-color-#{$key}{
    color: $value;
  }
}

Play with this gist on SassMeister.

Sassy Resources

All right! We’ve learned how to install and compile our Sass, set up a Gulp task to process our styles, create a file structure, and have seen a number of useful patterns. We are now cruising along smoothly at 60 mph.

However, it turns out that on this highway, there is no speed limit!

There are tons of really useful @mixins and @functions out there, and lots of people doing amazing things with Sass.

Sass is a powerful language, so it is also very easy to crash and burn. I recommend using tools like Sassmeister to keep an eye on the CSS that you are outputting.

In addition, take a look at the Sass Guidelines to make sure that you are writing sane, maintainable and scalable Sass code.

Want to learn more? Join us at the next ATL Sass Meetup.