Getting Started With SASS/SCSS: Introduction to CSS Preprocessing

Cascading stylesheets (CSS) are extremely powerful. Many of the fast loading, stylish websites we see on the World Wide Web are only possible because of CSS. There are some frustrating areas where CSS almost feels incomplete. Developers will often write the same fragments of code over and over both within the same project and across projects. Changing one colour often involves a search and replace when a variable at the start of the document would be a nice clear way to control this for example. It doesn’t matter if you’re the owner of an online sofa store or want your business blog to feel that extra bit special, CSS is essential for producing the most stylish websites around.

SASS (Syntactically Awesome Stylesheets) aims to fix these problems by introducing “nested rules, variables, mixins, selector inheritance and much more”. (sass-lang.com). It is a stylesheet language that allows developers to write in this extended language and then have that processed into plain CSS for use on the live website. SCSS is an evolution of SASS where curly brackets were returned to the syntax bringing it into line with the format of CSS itself. The examples given will be SCSS throughout this article.

Nested Rules

Chris Coyier gives a nice example of how the preprocessor handles nesting. Nesting allows developers to simply include the various additional elements such as :hover within one set of brackets instead of having to write out each element separately. Whilst this example is simple and would have saved merely a couple of seconds, more complex sites and designs will see significant benefits from this extension of plain CSS (which does support logical nesting but not the actual nesting of the blocks of code).

a {

 color: red;
 &:hover {
 color: pink;
 }
 }

becomes:

a {

 color: red;
 }
 a:hover {
 color: pink;
 }

source: CSS-Tricks

Variables

Variables are likely to be the most powerful addition brought by SASS. The earlier example of having a colour throughout the site is really cool but it’s a small advantage – a search and replace across the couple of CSS files a site will typically have won’t put anyone out too much. However, variables in CSS offer all the advantages they have in more traditional programming languages.

$contentwidth: 1000px;

.column {
 width: $contentwidth / 2;
 }

becomes:

.column {
 width: 500px;
 }

The beauty of this arrangement is that if our client decides a content width of 900px would be more optimal we don’t need to rework all our calculations that rely on that width. Everything from sidebars, maximum image sizes, columns and widget areas could be derived from some core variables defined at the top of the SCSS document and easily changed. I’m sure you can now start to see some of the real power of variables. With a lot of useful functions such as darken(); for colours allowing more sophisticated manipulation of variables the possibilities for SASS as it develops are endless.

Mixins

CSS requires any code that is used in more than one place to be repeated in full. SASS replaces this with mixins which allow repeated fragments of code to only be entered in one place and even providing arguments for customisation of these as they are re-used throughout the document. Let’s look at an example for a dotty border that is going to be used in various widths throughout the site.

@mixin dotty($dottywidth) {
 border-width: $dottywidth;
 border-style: dotted;
 border-color: black;
 }

.dottyborder {
 @include dotty(5px);
 }

becomes:

.dottyborder {
 border-width: 5px;
 border-style: dotted;
 border-color: black;
 }

This powerful ability to not only re-use but provide arguments to amend fragments of code allows for changes to be made quickly and easily to the core building blocks of your styles without editing dozens of separate locations.

Selector Inheritance

If a CSS selector needs to inherit all the styles of another the code would need to be repeated in CSS. In SASS this can be automated. The example on their own website is the best here so is just repeated below.

.error {
 border: 1px #f00;
 background: #fdd;
 }
 .error.intrusion {
 font-size: 1.3em;
 font-weight: bold;
 }

.badError {
 @extend .error;
 border-width: 3px;
 }

becomes:

.error, .badError {
 border: 1px #f00;
 background: #fdd;
 }

.error.intrusion,
 .badError.intrusion {
 font-size: 1.3em;
 font-weight: bold;
 }

.badError {
 border-width: 3px;
 }

Notice how .badError inherits .intrusion from .error.

Some Issues To Be Aware Of

Working on a live site will be more difficult if not impossible if you make the switch to preprocessing your CSS using SASS. This is probably a good thing for your productivity in the long run and switching to working with a local development environment keeps your live sites safe from any problems. When working with a team of developers, all would need to be experienced and capable of working in SASS for the switch to be made – this can be a factor as parts of your team having to learn SASS for a project could cause some initial teething problems.

All in all, however, most developers who have switched to preprocessors for developing their CSS report some productivity gains and the potential benefits are huge – particularly the customisations allowed by variables and mixin arguments. With clients often requesting small changes that need a lot of rewriting CSS these time savings will soon add up.