How many times when you work on a website do you need to declare the value of a color in CSS? Usually as a hex (hexadecimal) value like #bfbfbf. 10 times? 20? However many it ends up being, I often (in fact usually) struggle to remember hex values, especially with 2-3 colors in a site. With Sass, we can just define the colors as variables. A variable is merely a mechanism for referencing a value. Take at look at these three variables:

$red: #ff0b13;
$blue: #091fff;
$green: #11c909;

.i-want-to-be-green {
  color: $green;
}

.i-want-to-be-green {
  color: #11c909;
}

RGBA (Red Green Blue Alpha) and HSLA (Hue Saturation Lightness Alpha) colors are supported increasingly in modern browsers. To provide a fallback for older browsers it's common to declare a hex color value first and then an RGBA or HSLA value for newer browsers (that way, new browsers use the RGBA/HSLA, while older ones use the solid hex value). To exemplify that technique, to enable a color with some alpha transparency, at present we might do this:

.color-me-bad {
  color: #11c909;
  color: rgba(17, 201, 9, 0.9);
}

If picking colors from a composite in a graphics application (Photoshop, Fireworks, and the like), it is not always simple to get both hex and RGBA values. Before Sass, I had a handy little application just for the job. Now, I am pleased to say that thanks to Sass, that application has gone the way of the Dodo. With Sass, it is possible to simply do this:

.color-me-good {
  color: $green;
  color: rgba($green, 0.9);
}

We're using an easy to remember variable name to represent the color and then using a color function of Sass to convert that color to RGBA. In the preceding example we are asking Sass to give the value of the color (defined as the $green variable) as an RGBA value with an alpha channel at 0.9. When compiled, it produces the following CSS code:

.color-me-good {
  color: #11c909;
  color: rgba(17, 201, 9, 0.9);
}

For those in the cheap seats not paying attention, Sass has automatically provided the color as an RGBA value. The alpha channel is at 90 percent. This means that we can see 10 percent of whatever is behind the color in browsers that understand RGBA.

I'm a big fan of CSS3. It lets us ditch images and do more things with pure CSS than ever before. However, implementing these new features (background gradients, box-shadows, transformations, and a few more), that are often still experimental features, often requires the use of vendor prefixes and occasionally different syntaxes. You know the drill. As an example, this is what historically has been needed for rounded corners:

 .rounded {
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  -ms-border-radius: 4px;
  -o-border-radius: 4px;
  border-radius: 4px;
 }

With Sass's authoring framework, Compass, we get heaps of free mixins (don't worry about what a mixin actually is, we'll get to that shortly). Instead of remembering prefixes and associated syntaxes, you can just write the following code:

.rounded {
  @include border-radius(4px);
}

And that would produce exactly the same CSS on compile; all of the vendor prefixes get automatically generated. It's a huge time saver.

Sass allows rules to be nested within one another. So for example, if you wanted to make a set of links with a nav element and provide alternative pseudo states for hover and active states, you could write this in Sass:

nav {
  a {
    color: $red;
    &:hover {
      color: $green;
    }
    &:visited {
      color: $blue;
    }
  }
}

We are putting the anchor links (the a tag) within the nav element and also nesting the hover tag and visited states within the a tag. This probably looks more complicated than it actually is. Here's how that compiles to CSS:

nav a {
  color: #ff0b13;
}
nav a:hover {
  color: #11c909;
}
nav a:visited {
  color: #091fff;
}

I like to do this on little self-contained modules of CSS as it keeps all the associated styles together, especially where pseudo classes (like :hover and :active) are needed.

#container .callout-area ul#callout-one li.callout-list a.callout-link {
  color: #bfbfbf;
}

.callout-link {
  color: #bfbfbf;
}

Unless there is a good reason not to, I believe all websites should be built responsively (cough, buy my book Responsive web design with HTML5 and CSS3). In CSS terms, this typically involves writing lots of media queries for the different breakpoints in a design. For example, to change the typography at a certain viewport/device width you might write this CSS:

@media only screen and (min-width: 280px) and (max-width: 479px) {
  .h1 {
    font-size: 1.1em;
  }
}
@media only screen and (min-width: 480px) and (max-width: 599px) {
  .h1 {
    font-size: 1em;
  }
}
@media only screen and (min-width: 600px) and (max-width: 767px) {
  .h1 {
    font-size: 0.9em;
  }
}

That code sets a different font size on the h1 element depending upon the screen width in pixels. Personally, I think this is quite verbose and a lot to remember.

With Sass, instead, it is possible to do this:

h1 {
  @include MQ(XS) {
    font-size: 1.1em;
  }
  @include MQ(S) {
    font-size: 1em;
  }
  @include MQ(M) {
    font-size: 0.9em;
  }
}

A variable is defined for XS, S and M elsewhere (each is just a width value). The value of the variable is then used inside a mixin called MQ. Using that MQ mixin, media queries can be placed easily wherever they are needed, arguably making it simpler to understand where they are being applied in the code.

I've talked about some of the compelling features of Sass and Compass and not even mentioned @extend, placeholder styles, partial files, or image sprites; I hope you'll stick around for later chapters when we get into using them. In the meantime, as Columbo and Steve Jobs would say, 'Just one more thing…'.

How do you compress CSS before using it on a live site? Compressing the CSS makes it a fraction of its original size, resulting in faster code for every device that requests it. Compressing CSS can easily reduce the file size by half its original uncompressed size. Sure it's possible to copy and paste the CSS into an online compression tool, or perhaps your text editor has a built-in feature for the task, but Sass is better still. It just does it.

Sass can be configured to compile the CSS in a number of formats, one of which is compressed. So as soon as the Sass file is saved, it gets automatically compiled into compressed CSS; production ready and in the smallest possible file size. A time saver and something every user of the sites you build will benefit from, even if they don't know it.

So that's it; I've given you a few brief nuggets of what Sass and Compass can do. Next, let's get a handle on what Sass and Compass actually are and then we'll get up and running.