Introduction to Sass — Part 2

Posted: 22 Sep 2015 05:30 AM PDT

If you've never worked with Sass or another CSS preprocessor before, you might be surprised how easy they are to use. It's as easy to get started writing Sass as writing the CSS you already know.

Last week I mentioned you could start learning Sass by writing CSS in a .scss file. This week I'm going to show you. Then I want to talk about the different styles of output you can create when compiling Sass. I'll toss in a few words about adding comments to your Sass files.

Next week we'll begin to look at the features of Sass, starting with nesting, which is the first feature of Sass you're likely to use. I'll follow that up the week after with a look at Sass variables.

Using Sass

Sass code will naturally look a lot like CSS code. The easiest way to show you how to write Sass code is with a simple example. First here is a block of CSS code that might live in a file named style.css

1  2  3  4  5  6  7  8

body {      background: #fefefe;    }    .container {      max-width: 80%;      margin: 0 auto;    }

Here's what it might look like as Sass in a file named style.scss

1  2  3  4  5  6  7  8

body {      background: #fefefe;    }    .container {      max-width: 80%;      margin: 0 auto;    }

Can you spot the difference? It's a trick question as the code in both cases is exactly the same. The only difference is the name of the file.

You won't normally write your Sass exactly as you would write CSS, but I wanted to show you that making the jump to Sass is easier than you might think. If it's valid CSS it's also valid Sass.

Once you start working with Sass, you'll start to take advantage of more of its features and your code will look different. How different will depend on how many features of the language you decide to use.

I do want to make it clear that to start writing Sass is really as easy as writing the code you already write in a file with a different extension. From there you can begin to nest your code and use variables, which were the first two features I added, before adding more and more features that you find helpful.

The Original Sass Syntax

There are actually two different syntaxes you can use with Sass. The one I used above is the SCSS syntax, which requires you give your Sass files a .scss extension. This syntax looks like css, which is why I and many others choose to use it.

The original SASS syntax doesn't use the curly brackets or semi-colons. It relies on indenting and requires a .sass extension. My SCSS code above could be written in the original Sass syntax as:

1  2  3  4  5  6

body      background: #fefefe    .container      max-width: 80%      margin: 0 aut

You can decide which you prefer. I like having the brackets and semicolons, because I find it easier to read and because it looks like the CSS I was already writing. However, there's nothing better or worse about either syntax. Choose whichever you prefer, but know I'll be using SCSS throughout this series.

Output Style

I mentioned above you can output your Sass in a few different ways. You have four options for how to compile your Sass code, each with it's own pros and cons. The four ways are:

:nested
:expanded
:compact
:compressed

Let's say you wrote the following precompiled Sass.

1  2  3  4  5  6  7  8  9  10  11  12  13

.container {     color: #fff;     background: #363;    }    .container p {     width: 75%;    }    nav {     font-family: Georgia;     font-size: 0.875em;    }

You now have four choices for how the compiled code will be presented as CSS. Following are examples of each along with a brief definition of the output style.

:nested is the default Sass style and it will look like this when output. The only difference from the original is the curly braces have jumped up a line.

1  2  3  4  5  6  7  8  9  10

.container {      color: #fff;      background: #363; }    .container p {      width: 75%; }    nav {      font-family: Georgia;      font-size: 0.875em; }

:expanded drops the closing curly brace back to its own line, which is probably a little easier to read. The curly braces are dropped to a new line, even if they had been included at the end of a line of CSS.

1  2  3  4  5  6  7  8  9  10  11  12  13

.container {     color: #fff;     background: #363;    }    .container p {     width: 75%;    }    nav {     font-family: Georgia;     font-size: 0.875em;    }

:compact is like writing css selectors on a single line. Notice that the line breaks between selectors are preserved. If you prefer this style, you'll probably want to remove the extra lines between selectors in your Sass.

1  2  3  4  5

.container { color: #fff; background: #363; }    .container p { width: 75%; }    nav { font-family: Georgia; font-size: 0.875em; }

:compressed strips out whitespace and minifies the resulting .css file. You won't find reading this output easy, but this is really what you should use for production code.

1	.container{color:#fff;background:#363}.container p{width:75%;}nav{font-family:Georgia;font-size:0.875em;}

While developing, pick whichever of the first three outputs is easiest for you and then use :compressed when it's time to output for production.

Last week I mentioned you could use the following command to watch for changes to your .sass file and compile them into a .css file.

1	Sass --watch style.scss:style.css

To control the output style you can add the –style flag to the end of the command.

1  2  3  4

Sass --watch style.scss:style.css --style nested    Sass --watch style.scss:style.css --style expanded    Sass --watch style.scss:style.css --style compact    Sass --watch style.scss:style.css --style compressed

Hopefully I'm not doing too bad with the commands, given I rarely use the command line for anything.

Comments

It's good to comment your code to make it more readable for others and for yourself when you come back to a project after a few months away.

You can use both single line and multi-line comments in your Sass code

1  2  3  4  5  6

// single line comment    /*  multi-line  comment  */

Multi-line comments will compile into the CSS file. They'll still be comments, but anyone viewing the CSS file will be able to see them.

If you want a comment to be in the Sass file, but not the CSS file use single line comments as they'll be removed during the compile.

Closing Thoughts

You might be wondering at this point, what the big deal is and why you'd want to use Sass since it probably seems like a more complicated way to write CSS. I promise there's more to Sass and I'll get to it starting next week.

Beginning to work with Sass is as easy as renaming your .css file to .scss or .sass and then writing CSS the way you always have or mostly the way you always have. You can compile your Sass code either through the command line or by using an app that will compile the code for you.

Once you have everything set up and get used to compiling the additional file, you can slowly integrate the features of Sass into your workflow.

When compiling your Sass, you'll probably want to use one of the the output styles that's easy to read until it's time to compile for production, at which point you should choose the :compressed output style.

I'll start to talk about the basic features of Sass next week when we look at nesting. The following week I'll talk about working with variables.

Download a free sample from my book Design Fundamentals.

The post Introduction to Sass — Part 2 appeared first on Vanseo Design.