Writing style sheets with Sass and Compass makes them more flexible, more maintainable, and faster to produce than ever before. That's why companies including eBay, bet365.com, BBC, Instagram, LinkedIn, Square, and Groupon all use Sass and Compass to produce their CSS.
One thing that kept me away from using Sass for too long is how difficult it seemed to get up and running. The thought of needing to use the command line to get something working made me tremble with fear, so when instructions included phrases like 'install ruby gems' and 'run the watch command', I was lost. In the words of Dr Evil, "Throw me a frickin' bone!"
If you're primarily a designer, you may have had a similar reaction. The aim of this book is to make Sass and Compass as understandable and easy to use as possible. That way all of its incredible features can be put to good use right away. I want to assure you right now that if you can write HTML and CSS you can easily master Sass and Compass.
Sass describes itself as a meta language. It's more commonly described as a CSS 'preprocessor'. Either way, the reality of using Sass is simple. Code is written as one file (a Sass file with an extension like .scss) and when the file is saved, Sass converts it into the same CSS you already know how to write (and if you don't know how to write CSS, put this book down and move to another shelf).
It's actually simple to make a Sass file too. Take any existing CSS file and change the file extension from .css to .scss. That is now a fully functional Sass file that you can add extra Sass based functionality to; just think of Sass as supercharged CSS.
If the command line side of things still bothers you, fear not. There are now a number of user-friendly graphical tools to make working with Sass and Compass simple. We'll cover those in this chapter (as well as using Sass and Compass from the command line for those feeling brave).
As this book is aimed at designers, after extolling the virtues of Sass and Compass, this chapter is primarily focused on understanding what Sass and Compass are, how the two relate, and then getting them both installed. Then we will be ready to start our first project.
In summary, in this chapter we will learn:
Why CSS preprocessors are needed
Why you should use Sass and Compass
What Sass is
What Compass is and how it relates to Sass
How to install Sass and Compass on OS X and Windows
Which graphical tools are available to negate the need to use the command line
The different syntaxes of Sass
CSS is a declarative, not a programming language. This simply means that the style properties and values that we declare within the rules of CSS are exactly what the browser uses to paint the screen. A programming language on the other hand provides some means of defining logic. Crudely put, a logical statement might be in the form of: if the h1 elements are in a nav element, make them blue; if they are in the header elements, make them red. A programming language also facilitates
variables. These can be thought of as placeholders for something reusable (for example, one might have a variable for a specific color value). Then there are functions, a means to manipulate values with operations (for example, make this color 20 percent lighter). Sass and Compass provide these capabilities and more.
If some of the terminology in that last paragraph sounded alien, fear not. We will be dealing with all those concepts in due course. For now, let's just consider some common misgivings about CSS preprocessors.
My initial reaction when looking at the CSS preprocessor Sass was, 'If it ends up producing CSS, why don't I just write CSS?' Turns out, this is a reaction many people have. After all, we use CSS everyday. We can (hopefully) use it to fix all the usual layout problems that get thrown at us, build responsive websites that are displayed beautifully on all devices, and generally make ourselves feel like, for the most part, we know what we are doing.
Let's be clear from the outset. Sass won't necessarily make us produce better CSS. For example, if you don't understand how to use CSS now, Sass and Compass won't fill that gap in your knowledge. However, Sass enables us to write CSS faster and more easily while also keeping the style sheets far more maintainable.
Tip
Sass, LESS, or Stylus?
The chances are, if you are reading this, you have already done a little research and decided to look into Sass as opposed to LESS or Stylus. LESS and Stylus are also CSS preprocessors that do similar things to Sass. It is my humble opinion that Sass is a better and more powerful language, although I'll concede that the documentation for LESS in particular can make it seem easier to get to grips with. However, if you'd like to read a good summary of the various pros and cons of Sass and LESS, take a look at this great post on the CSS Tricks website, written by CSS maestro Chris Coyier: http://css-tricks.com/sass-vs-less/.
As mentioned previously, there is a growing number of organizations such as the BBC, eBay, and LinkedIn that have already embraced Sass and Compass and use it to write and maintain their style sheets. It stands to reason that when large organizations are switching from writing CSS directly to using the Sass preprocessor there must be some enormous economies to make it worth their while. There are! So let's take a brief look at some of the headline features of using Sass now. This is by no means an exhaustive list, but hopefully it provides a tantalizing taste of what's possible and how Sass and Compass can make writing CSS easier than ever before.
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;
The dollar sign indicates to Sass that we are defining the start of a variable. Then comes the name of the variable (with no space after the dollar sign). Then a colon indicates the end of the variable name, meaning that the value will come after the colon but before a closing semicolon. In this case, the variable $green is going to be the color of green we want as a hex value. With those colors defined as variables, we can use them anywhere in the Sass style sheet like this:
.i-want-to-be-green {
color: $green;
}Here is the CSS generated on compile:
.i-want-to-be-green {
color: #11c909;
}Note
In Sass, compile just means to go from Sass to CSS.
In Sass speak, you will see the term 'compile' used frequently. For our purposes, all you need to know is that compile just means go from Sass (in either .scss or .sass format—more of which shortly) to CSS. See? Easy!
Writing and remembering variable names is far easier than remembering unnatural hex values, no? Furthermore, when those color values need to change, they only need changing at the variable and everywhere else takes care of itself. No more 'find and replace' when the colors in a design change—Woo Hoo!
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.
Note
Keep in mind that it's rarely good practice when writing CSS selectors to make them too specific. For instance, here is an example of the kind of CSS rule that can make life difficult:
#container .callout-area ul#callout-one li.callout-list a.callout-link {
color: #bfbfbf;
}The resultant selector is many levels deep, making it very specific. From a maintainability point of view it would be far easier to simply have this to achieve the same effect:
.callout-link {
color: #bfbfbf;
}So, keep in mind that just because you can nest rules doesn't mean you always should.
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.
The website of Sass (http://sass-lang.com/) makes this description of Sass:
Sass is a meta-language on top of CSS that's used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable style sheets.
The Sass website also provides some insight in to how Sass came about and developed. Sass was first given life by Hampton Catlin (also the creator of HAML) in 2006. Since then, it has been fostered, loved, and cared for by a number of others. However, most notable in the development of Sass is Nathan Weizembaum (the primary designer and developer who developed Sass with Hampton Catlin until Version 2) and Christopher Eppstein (who joined Weizembaum on the Sass core team in 2008 and developed the project with him from Version 2.2 onwards. Eppstein is also the creator of the Compass framework). There are also a number of other contributors to the Sass project. The project's GitHub development homepage can be found at http://github.com/nex3/sass.
As Sass started life in the Ruby community (Ruby is itself a programming language), much of the documentation associated with Sass has always been programmer friendly. Historically, this has made Sass difficult for non-programmers to get their heads around. This is a great shame, as designers who also write their own frontend code arguably stand to benefit as much as anyone else from its power and features.
Note
Sass also supports two syntaxes. The original syntax (known as Sass, with files ending in a .sass extension) is terse and based on indentation. It removes the curly braces we're used to seeing in CSS. You can find more documentation on the indented syntax at http://sass-lang.com/docs/yardoc/file.INDENTED_SYNTAX.html.
The syntax we will be using throughout this book is the SCSS based syntax, with Sass files ending in the .scss extension. This syntax is more verbose than the original indent-based syntax but similar to existing CSS.
Wynn Netherland, Nathan Weizembaum, and Christopher Eppstein have their own book on Sass and Compass, Sass and Compass in Action. As Nathan Weizembaum and Christopher Eppstein are the current maintainers of Sass, while the title isn't specifically targeted at designers, it may be worth your attention. Take a look at http://manning.com/netherland/.
Sass is free to use, requiring no license.
The Compass website is at http://compass-style.org. It describes itself as follows:
Compass is an open-source CSS Authoring Framework.
In fact, Compass was the first Sass-based framework. What this boils down to is that by installing Compass alongside Sass we get access to lots and lots of reusable patterns and tools for easily creating CSS. Have you seen the TV show Pimp my ride? If Xzibit took Sass into West Coast Customs, Compass would be the first thing they added!
Put another way, Compass lets you write CSS3 goodies like box-shadow, gradients, columns, and transforms with a single syntax, and it magically creates cross-browser compatible CSS of everything that just works without headaches. It also paves the way for additional plugins to enable incredible, lightweight grid systems that we will be looking at in due course.
The project's GitHub development homepage can be found at https://github.com/chriseppstein/compass.
Note
Note: Compass is charityware. This means that while you can use it as much as you like, you are encouraged to make a donation to help the UMDF find a cure for mitochondrial disease. Once you use Compass and realize how much time it saves, I'd encourage you to make a donation at http://umdf.org/compass/.
In days gone by, to use Sass and Compass, it was necessary to use the command line to install them. Don't worry, those days are over. If you're not a fan of the command line, you don't have to use it. There are now a number of graphical tools for OS X, Linux, and Windows that will include all the necessary files to compile Sass files to CSS whenever they are saved. However, while we'll look at these tools, we can totally install Sass and Compass from the command line. Are you ready? Let's do this.
If you'd rather not, I understand, just skip ahead to the section on graphical tools. You can always come back here later. I won't judge!
For those using Mac OS X, it is really simple to install Sass and Compass. Compass creator Chris Eppstein has created a graphical installer package. Just head to https://github.com/chriseppstein/compass/downloads, download the package, and run the latest installer.
However, understanding just a little about the command line will be beneficial, so you may opt to flex your command line muscles just a little and install from there.
Tip
Getting around on the command line
There are only a few commands that are essential to work with Sass and Compass on the command line. Following are the ones you'll probably need to know:
List the items in the current folder:
Windows:
dir
Mac:
ls
Change directory/folder—moving to another folder within the current one:
Windows and Mac:
cd folder-name
Here folder-name is the name of the folder you want to change to
To move to the parent folder:
Windows:
cd..
Mac
cd ..
Before we can install Sass and Compass, we need Ruby installed. If you are on OS X, you already have it.
If you are on Windows, head over to http://rubyinstaller.org/downloads/, download, and install the latest Ruby installer file (for example, it will be a file link as follows, depending upon the current version: http://rubyforge.org/frs/download.php/76054/rubyinstaller-1.9.3-p194.exe). Just use the defaults (you don't need to put any tick boxes in the options). Linux users should be able to install Ruby direct from their package manager.
I'm assuming if you are running Linux you are savvy enough to understand what to do, if not, I'd suggest getting a Mac!
Now, regardless of the system (Windows/Linux/Mac), we have Ruby ready. We're going to use the Ruby gem command. Basically, we are just saying, "Ruby, install me the 'gem' called 'compass'". Compass actually requires Sass, so by installing Compass, Ruby will automatically install Sass too.
Note
Think of a gem as a tiny application or plugin; it simply extends the functionality of something that uses Ruby. Because Sass and Compass use Ruby, once you get into Sass, you'll often find yourself downloading new gems. For example, there are gems for grid systems like Susy, gems for button styles like Sassy Buttons, and lots, lots more.
Those on OS X should open the Terminal application. It's typically located in the Applications | Utilities folder. Here's the Terminal application in my Finder:
Double-click on that and you'll see a window like the following screenshot:
In case you've never been here before, this is the command line! Now just type this and then press Enter:
sudo gem install compass
You will be prompted for your user password (it's the same one you use to log into your desktop). Just type it in and press Enter. Don't be alarmed when it seems that nothing is happening. When entering a password, the Terminal provides no feedback. With that done, Compass and Sass will install.
How about that, you just installed a Ruby gem. Do you feel like a nerd now? Don't worry, it'll be our little secret.
For Windows
users using Windows 7 or Vista, just click on the Start button and type ruby, and then click on the highlighted Start Command Prompt with Ruby option. Those on Windows 8, from the Start screen, right-click, choose All apps, and then click on the Start Command Prompt with Ruby option.
The Command Prompt will now open as shown in the following screenshot:
Just type the following command and press Enter:
gem install compass
Compass and Sass will now install, and when finished you will be presented with another Command Prompt (a blinking cursor).
There, that's all there is to it. Sass and Compass are installed; you can now start writing Sass and Compass files.
As new features get added to Sass and Compass from time to time, it's worth knowing how to check your current version and install the latest versions. Check the current version of Sass from the command line with the following command:
sass –v
You will see a response, something like Sass 3.2.5 (Media Mark).
To check the current version of compass, run the following command:
compass –v
You will get a
response on the command line such as Compass 0.12.2 (Alnilam).
Of course, it's possible to check the websites of Sass and Compass to find out which versions of each are available, but this can also be done from the command line. Just run the following command:
gem list sass –a –r
We are just asking Ruby to list the versions of all the gems that have sass in their name. The -r part of the command is asking Ruby to check remotely (for example, on the Internet as opposed to on your own system) and the -a part is just asking Ruby to list all the versions. Here's the same command for Compass:
gem list compass –a –r
With either of those commands, you'll get a list of all the gems that contain the word Sass or Compass respectively, with the version numbers listed in brackets. For example:
sass (3.2.0, 3.1.21, 3.1.20, 3.1.19, 3.1.18, 3.1.17, 3.1.16, 3.1.15, 3.1.14, 3.1.13, 3.1.12, 3.1.11, 3.1.10, 3.1.9, 3.1.8, 3.1.7, 3.1.6, 3.1.5, 3.1.4, 3.1.3, 3.1.2, 3.1.1, 3.1.0)
The versions are listed in reverse chronological order (latest first).
To check which prerelease versions are available, the command is:
gem list sass --pre -r
To check which prerelease versions of Compass are available, the command is as follows:
gem list compass --pre -r
To install the latest
stable version of Sass, just run the following command (the sudo part may not be needed depending upon your system configuration):
sudo gem install sass
If a future version has something exciting you want to try out but it isn't yet a full stable release, you can install the latest prerelease version by running this command:
sudo gem install sass --pre
However, be aware that there may be bugs and inconsistencies with the latest version. So, unless you have a specific reason to do so, I'd recommend only using the stable versions.
It's the same style of command for Compass:
sudo gem install compass
And for the prerelease version:
sudo gem install compass –pre
Tip
How to uninstall a specific version of Sass
Now, should things go pear-shaped at any point, you can roll back to a previous version of Sass by using the following command:
gem uninstall sass --version versionnumber
Here, versionnumber is the release you want to remove (for example, 3.2.0.alpha.103).
Want to create a
Sass and Compass project from the command line? This can be done by changing folders in the command line to where the site folder should be (for example, I tend to keep mine in a folder called Sites) and running this command:
compass create my-project
Hopefully that command is self-explanatory; we're just using Compass's built-in create command to make a project in the folder specified. For example, the my-project part is the name of the project folder that will be created. Compass then creates a number of files and folders. Following is an example of the resultant files in Windows:
Tip
What are the generated files in a Compass project for?
We'll cover what the various files and folders do in depth in Chapter 2, Setting up a Project based on Sass and Compass. In the meantime, here's a quick overview of what each does:
.sass-cache: This folder will contain the cache files that Sass uses to build your CSS files faster. You don't need to do anything with it.
sass: This folder will store the Sass files that will be written or amended. This folder can be called anything, but 'sass' is the default name.
stylesheets: This folder will contain the compiled CSS files that Sass will generate. It can be called anything, but stylesheets is the default folder name in Compass projects.
config.rb: This file contains the configuration defaults for a project, what the various folders are called, and where they are located. It also controls the compression style of the generated CSS.
To have Compass 'watch' the
Sass files for changes (which are in the sass folder of the project) and automatically compile them into CSS on save, it's necessary to first browse to the folder that holds the Sass files being worked on (it may help to refer back to the Getting around on the command line tip box in the Install Sass and Compass section for the relevant commands). When at the root of the relevant folder (when listing the contents of the folder you are in, the config.rb file should be listed) run this command from the command line:
compass watch
This Compass command just says "Compass, watch this project, and if any Sass files change, recompile the CSS". Now, whenever the Sass files within are changed, Compass will automatically note any changes and recompile the equivalent CSS files (the CSS is compiled into the stylesheets folder of a Compass project by default).
There are a number of graphical tools that handle all of this Ruby gem shenanigan business (they all include their own versions of Ruby) and compile Sass files into CSS. The three we will look at are LiveReload (OS X and Windows), CodeKit (OS X only), and Scout (OS X and Windows).
I initially used the command line to work with Sass and Compass, but nowadays, unless there are specific commands I need to run, I tend to use LiveReload or CodeKit day-to-day. However, there is no right tool to use. Just use the one that works best for you.
Whichever you choose, in a few clicks, all the business of watching files for changes is handled automatically. Just ensure the application is running and get on with writing Sass files.
Scout is a free Adobe Air-based application. It can be downloaded at http://mhs.github.com/scout-app. Once installed, run the application and click on the big plus button at the bottom left of the interface to add a project. It's still necessary to configure the settings, but once done the compile process will be automated. It's free, but personally I think it's worth investing a little money on one of the other solutions (described next) as they offer extra functionality that can soon pay for itself.
CodeKit is a Mac OS X only application (sorry Windows and Linux folks). It has a great, simple user interface and not only compiles Sass files (along with a bunch of other preprocessor languages), it also reloads the browser window as files are saved; a real timesaver when iterating over styles. It can also concatenate files and a whole lot more.
What is particularly nice about CodeKit is that it gives the option to create Compass projects directly from the interface. Just specify the preferences, choose a folder, and it does the rest (and then automatically watches the project for changes).
The full version is $25, but there's a free, time-limited trial, so take a look and see if it works for you: http://incident57.com/codekit/.
LiveReload is similar to CodeKit, in that alongside automatically compiling preprocessor languages such as Sass, it also automatically refreshes the browser window as changes to web-related files are made. Just press the plus icon at the bottom of the interface, browse to the project folder, and then tick the Compile SASS, LESS, Stylus, CoffeeScript and others option.
It costs $9.99 (available to OS X users through the App Store). Alongside the OS X version there is also a prerelease version available for Windows. Take a look at http://livereload.com.
Text editors are like sports teams; everyone has their favorite. There isn't a right or wrong text editor to use with Sass. However, using one that supports the Sass syntax will obviously be beneficial as it will provide lovely syntax highlighting that makes the files easier to work with.
Thankfully, most quality text editors either support Sass syntax out of the box or have third-party plugins that extend the functionality to include syntax highlighting for Sass. At the time of writing this, my current text editing application of choice is Sublime Text (cross platform, available at http://sublimetext.com), although programs like Coda 2 (OS X only, available at http://panic.com/coda), Espresso 2 (OS X only, available at http://macrabbit.com), and Aptana (cross platform, available at http://aptana.com) also have native support for Sass.
In this chapter, we have looked at a few reasons to use Sass and Compass. We have also considered exactly what each is, does, and how the two relate to one another.
Then we've either installed Sass and Compass from the command line (and wrapped our heads around what Ruby gems are) or opted to use any one of the growing number of graphical tools that support Sass and Compass. Either way, we now have some mechanism in place to watch our Sass files and automatically create CSS files whenever they are saved.
Hopefully one of the biggest hurdles, getting Sass and Compass set up, is now dealt with. We can now get on with starting our first Sass and Compass project. That is exactly what we will be doing in the next chapter. We will learn all about how to amend the configuration file, the various ways we can comment Sass files, make use of partial files, and use variables for cleaner and more maintainable style sheet authoring.
