Introduction to Sass: Part 2

Show Notes

Welcome to part two of our Introduction to Sass. If you’re new to Sass, start with our first Introduction to Sass screencast. We’ll be building on what we’ve learned there.

In this screencast we’re going to cover some more of what Sass has to offer, including the @import rule, partials, interpolation and more.


What you'll learn

How to use more of Sass' core features including:

  • Importing Partials
  • Referencing Parent Selectors
  • Interpolation
  • Comments

Introduction to Sass: Part 2

Welcome to part two of our Introduction to Sass. If you’re new to Sass, start with our first Introduction to Sass screencast available on We’ll be building on what we’ve learned there.

In our first Sass screencast we covered some of the awesome features built into Sass, such as variables, nesting, selector inheritance and mixins. In this screencast we’re going to cover some more of what Sass has to offer. So lets get to it.


Like CSS, Sass uses the @import rule to import files containing Sass. All imported Sass files will be merged into a single CSS file when compiled. Any declared variables or mixins will also be accessible to the importing file. If there’s no extension declared, Sass will try to find a file with the extension .scss or .sass, and import it.

So for example, if you @import "reset", it will compile down to the same as @import "reset.sass".

Here is the final compiled CSS.

You do have the option to include an plain CSS file with the @import rule, but just be aware that Sass won’t merge it’s contents with such a file, and it basically passes the import line through in its raw form. You probably won’t be doing this, but it’s good to know in case you encounter it.


You may notice that reset.sass is compiled down to reset.css. But this is already included in our styles.css, so we don’t need it to be compiled down into it’s own file.

To prevent it from being compiled down, all we need to do identify this file as a partial by renaming reset.sass to _reset.sass.

Sass has partials so that we can identify files which are intended to support other files. You may be familiar with this naming convention from how Rails names its partials.

It’s good to get in the habit of organizing your code into partials. It helps keep your project organized, and you can start building a library of reusable partials that will come in handy on future projects.

Referencing Parent Selectors: &

Referencing a rule’s parent selector can sometimes be handy, particularly when using pseudo classes like :hover.

So instead of writing the following:

We can write this in a more structured and organised way by using the ampersand symbol as a reference to the parent selector.

The ampersand also preserves deeply nested rules.

So this Sass gets compiled to this CSS:

While this indentation for the ampersand syntax may not seem to be in line with Sass’s other nesting rules, it’s definitely in-line with the overall "Sassy spirit" of keeping it clean and organised.

Interpolation: #{ }

You can use the pound sqiggley-bracket (#{}) interpolation syntax in selectors, properties and values. This can be particularly handy when using mixins. Let’s say we have a list of links and icons for RSS, Facebook, and Twitter.

In our link_icon mixin we have a $type variable. We can use this variable to dynamically add a class name, and use it to dynamically create the image url.

As you can see, interpolation is a great way to build dynamic CSS, and keeps your code DRY.


You may also want to write comments from time to time, to either debug or annotate your code for when you or a coworker comeback to it at a later date.

There are two types of comments you can write: First, Comments that appear in the final compiled CSS, which can be handy for debugging. And Second, comments that are purely for developers and won’t be compiled into the final CSS.

To write a comment that will be compiled, you’ll want to write /*, followed by your comment. You can also do multi-line comments by including spaces for nesting on the additional lines (You can also add a * to make it look pretty, and it still compiles nicely).

To write comments that won’t be compiled and will only be visible to developers who have access to the Sass, you’ll want to write two slashes // followed by your comment. Once again, if you want to do multi-lined comments, you simply add spaces for nesting on each additional line.

Thanks for watching! Subscribe to our RSS feed, follow us on Twitter, and please leave any questions, comments or suggestions for new screencasts in the comments below. If you like our videos, and think your friends, followers or colleagues would benefit from seeing them, please feel free share via any of the links below the video. We really appreciate your support.

See you next time!