The following article is composed of excerpts from a presentation I gave to my fellow designers at Hewlett-Packard in March, 2015.
What is Sass?
Sass actually stands for "Syntactically Awesome Style Sheets". It is a preprocessing language, or extension language for standard Cascading StyleSheets, or CSS. At a high level you could say that Sass enables you to write CSS styles faster and more powerfully than ever before. My favorite part of the preprocessing language is how Sass it enables a reusable and highly organized structure when writing a site's stylesheets. As you learn Sass, you'll find that it's core features are those that you have very likely wished were included in vanilla CSS. This is why it's been so quickly and warmly embraced by the front-end community. Stylesheets written in Sass (or SCSS) are compiled locally on the designers machine then generate a standard .css file for the browser to interpret.
Sass it enables a reusable and highly organized structure.
The core features that Sass introduces to CSS include; Variables, Nesting, Partials, Imports, Mixins and Extends. It's important to remember that standard CSS can also be written within the Sass syntax. No harm done.
Variables
Variables work by storing bits of information for future use in a stylesheet. They are typically defined near the top of a stylesheet for this reason. Though, this is not a hard-and-fast rule. Sass is a very flexible language, and most front end developers have their own best practices, suitable for their workflow(s).
Variables are a great way to define constants in a project. A simple example of this are brand colors and font stacks. Anything you plan to re-use and reference throughout a stylesheet is typically a good candidate to be defined as a variable. When/if you change a variable, it will be updated and processed properly everywhere it has been referenced in your styles.
A simple example of Sass variables in practice:
$brand_primary: #0096D6;
$brand_muted: #F2F2F2;
$primary-font: ‘Open Sans’, Helvetica, Arial, sans-serif;
body {
background-color: $brand_muted;
font-family: $primary-font;
}
a {
color: $brand_primary;
}
As you might expect, this will be processed locally and output the following code:
body {
background-color: #F2F2F2;
font-family: ‘Open Sans’, Helvetica, Arial, sans-serif;
}
a {
color: #0096D6;
}
Nesting
Nesting is exactly what it sounds like, nesting CSS declarations within one another. The primary benefit of this is how much easier it is to read and visually understand the hierarchy of a stylesheet at-a-glance. In addition, nesting allows for more specificity in the output CSS than you may write your styles with initially.
Nesting aids in keeping your stylesheets very DRY "Don't Repeat Yourself", a basic principle in programming. Nested Sass declarations visually mimic the HTML that they are targeting, which can aid in their understanding. This can be seen in the following example:
nav {
ul {
margin: 0;
padding: 0;
list-style: none;
}
li { display: inline-block; }
a {
display: block;
padding: 6px 12px;
text-decoration: none;
}
}
Partials
Partials are a great organizational tool introduced by Sass. They allow you to break down a single stylesheet into smaller pieces, or partial files. Smaller files are always easier to maintain and work with. This is especially the case when multiple developers are working on the same code-base and need to understand the work of others.
Partial files are denoted by beginning with an underscore (_). Sass will ignore these files, unless they are *imported* into another .scss file.
Imports
As mentioned above, Imports go hand-in-hand with Partials in Sass. An import will collect partials together into one CSS file. When writing an import, you do not need to include the file extension or the aforementioned underscore, Sass is smart enough to find the referenced partial files without this level of specificity.
CSS does already support an @import function, but it differs from that within Sass in a very important way. CSS import's are executed in the browser, resulting in an additional call to the server and more client-side processing. Sass is a preprocessing language, and thus its imports, on the other hand, are executed on the developers local development environment. This makes for faster webpages, if only by a little.
Import example:
@import 'colors';
body {
background-color: $brand_primary;
}
Mixins
Mixins allow for groups of CSS declarations to be reused throughout your stylesheets. They help to eliminate repeating tedious or more common bits of code. Defining mixins is similar to variables, but you instead use the @mixin syntax, seen in the example below.
A common example of mixins is to define the vendor prefixes common in CSS3 declarations, such as border radius:
Declaring a mixin:
@mixin border-radius {
-webkit-border-radius: 10px;
-moz-border-radius: 10px;
-ms-border-radius: 10px;
border-radius: 10px;
}
Calling, or referencing a mixin:
.box {
@include border-radius;
}
Extends
Extends allow you to share a set of CSS declarations. They are especially successful in keeping your Sass documents, and even the output CSS stylesheets very DRY. The generated CSS groups common styles by their selectors, and limits the amount of repetition in the code. This typically results in cleaner, shorter CSS for the browser to interpret.
The primary difference between an extend and a mixin is the fact that extends share code, while mixins reuse code. Use a mixin when the output CSS will be difference depending on the situation, and an extend when the output CSS can be shared between multiple elements or classes.
References & Links