What is Sass?
At its core, Sass is an extension of CSS that speeds up the development process and makes it easier to write more maintainable code. When you write in Sass, you are writing CSS with a few enhancements that make CSS easier to write. Sass includes all kinds of neat features that allow you to reuse code snippets and variables, so you can focus on writing great code that works.
You may thinking, “that’s cool, but what does it mean?” In the code snippet below, you can see Sass input in the first half and the CSS output in the second half. As you can tell, the Sass part is a lot more concise. Everything shown here will be covered in the sections below.
There are actually two syntaxes for writing Sass: one which does not include brackets or semicolons, relies on indentation and line breaks, and uses the file extension .sass; and the other which is written just like CSS with a few improvements, and uses the file extension .scss. The .scss syntax is the more commonly used of the two, so anytime we refer to something using Sass, it is in this format.
Comments in Sass
Sass includes its own commenting style, which is the same as JavaScript’s single-line comments. Any Sass comments are not output in the CSS, and can only be seen in the actual Sass files. This is great for anything you don’t want to appear in the actual CSS. It’s a good idea to use Sass comments for internal comments and CSS comments for anything external, but keep in mind that CSS comments will also be removed if the file is minified.
Partials & Imports
Instead of writing all your CSS in a single stylesheet, Sass allows you to split up styles into different files called partials. This promotes organization, makes it easier to find specific styles to edit, and promotes modularity.
To make a Sass file into a partial, it simply needs an underscore added to the front of the file name. So navigation.scss would become _navigation.scss. Partials need to be imported into your main stylesheet. In the example below, the partials for normalize, variables, and mixins are all called into the global.scss file. Since these three files can affect the rest of your styles, they should be imported at the top. Anything that uses styles, mixins, or variables from them should be included after.
Nesting
Unlike in traditional CSS, you can nest related rules in Sass. The output of nesting will include the same specificity that you might normally write in CSS, but it promotes readability and helps build visual relationships between rules. A general rule of thumb is to only nest four levels deep; too much specificity is not good for performance or maintainability.
When nesting, child elements should be included inside the brackets of the parent element, as shown in the example below. Once nested, you can directly refer to the parent element using an ampersand, which can be seen in the second example with the link.
Variables
Similar to other programming languages, Sass allows you to declare variables and call them elsewhere in the code. They are used in place of commonly used values, such as colors, fonts, breakpoints, z-index stacks, and more. Whenever the value of the variable changes, every instance where that variable is being used will update to reflect the change. This makes it much easier to swap color palettes or font families.
All variables will need a name, preceeded by a dollar sign. Variable names should be descriptive, without being overly verbose.
Types of Variables
There are two variable types: global and local. I typically store global variables in a _variables.scss partial so they can be used anywhere the partial is included. Local variables are defined in a specific rule and can only be used in that rule or its nested rules.
Interpolation
To use variables in a selector name or within parentheses, you need to use the interpolation syntax. As shown in the example below, this can be done by including the variable within curly braces and preceeded by a pound sign. Interpolation can also be used to prevent Sass from using its own mathematical operations and force it to render CSS instead, which is useful when using variables within the CSS calc function or for the font shorthand.
Mixins
Mixins allow you to reuse commonly used properties without having to type them over and over. At the base level, they just need to include at least one CSS property, like in the example below. Mixins are defined with @mixin followed by its given name. Like variables, mixin names should briefly describe what the mixin does. To use a mixin, call it with @include and then the name of the mixin. It’s a good idea to keep commonly used mixins in their own partial so that they can be reused easily without bulking up the main stylesheet.
Mixins with Arguments
Mixins can also take in arguments to allow for more customization. Arguments are declared directly after the mixin name and are listed as variables separated by commas. They can then be used in the place of specific values for rules. When using the mixin, you specify values for those arguments, making it more durable.
Mixins with Optional Arguments
To allow even more durability for mixins, you can make some of the arguments optional. Optional arguments are followed by a colon and a default value. If you don’t want there to be a default value at all, you can replace this with null. If the default value is listed as null, the rule that contains that variable will be ignored and won’t be output to the CSS. It’s also important to note that optional arguments have to be listed after all other arguments, but you can have multiple optional arguments.
Extends
Using the exact same mixin multiple times without changes to the arguments can bloat the resulting CSS. Instead, you can use the extend functionality to group together selectors with the same rules. This works with either a class or a placeholder selector, which is a rule that is never used on its own, similar to a helper class. Placeholder selectors are preceeded by a percentage sign, and are better to use with the extend functionality because the code within it will never be output on its own. If you were to use a class within an extend, you would still have the class output in the CSS.
There is one flaw to using extends in that they cannot be used in media queries unless it was defined within the same media query. If you define all of your placeholder selectors in a specific place, such as their own partial, they cannot be used in a media query. This is one of the quirks of extends, which is discussed in more detail in the Sass documentation.
While extends and placeholder selectors seem promising, they can quickly get out of hand. When using extends, your final CSS output will group all of the selectors that use the same extend. This can make for some very long selectors, which is not ideal. Additionally, this isn’t particularly useful if you are gzipping your CSS files, as gzip favors repetition.
Advanced Sass
There are lots of other things you can do with Sass, including:
- @if, @for, @each, and @while statements
- @functions
- Lists and maps (arrays)
- Mathematical, color, and string operations
Sass Syntax in Sublime Text
Sublime Text and other text editors do not natively support Sass syntax highlighting. To activate this in Sublime Text 2 or 3, you will need to install the “Sass” package using Package Control, which can be found here. In addition to syntax highlighting, this package also features tab and code completion, and is also available for TextMate. If you are using a different text editor, you will need to find an appropriate equivalent.
Compilation & Gulp Plugins
Because browsers currently cannot parse Sass files, they need to be compiled into CSS. I prefer using Gulp to handle this, which is a Javascript task runner that can run a number of different plugins to speed up your development process. The two Gulp plugins I use for handling Sass are gulp-sass and gulp-autoprefixer.
Source Maps
After compiling Sass, you can no longer rely on line numbers or file names for debugging purposes. If you were to inspect an element on the page, you would see that everything says it’s in the main CSS file, and the line numbers aren’t accurate because everything’s been minified. This is where Source Maps come into play. Source Maps can be used in conjunction with your browser’s development tools to display the Sass file that each style comes from, as well as more accurate line numbers.
To use Source Maps, you need to enable the option in the gulp-sass plugin. Doing this will create a new file in your CSS folder called yourstylesheet.css.map, which will be included at the end of your compiled CSS file. This lets the browser know which Sass files each style belongs to. If you still can’t see this in the inspector, check the development tools’ settings under General and Sources, and make check the boxes for “Enable CSS source maps” and “Auto-reload generated CSS”. For more information on using Source Maps, check out these articles from Thoughtbot and the Sass Way.
Additional Resources
There are lots of great resources out there for both learning Sass and getting more advanced with it: