Introduction to Sass — Part 1

Posted: 15 Sep 2015 05:30 AM PDT

CSS preprocessors have become part of many designer and developer workflows over the last few years as they help you write and maintain complex CSS code. They offer some of the features of programming languages when you want them, allowing you to ignore them when you don't.

I realize there's a good chance you already use Sass or maybe Less or Stylus or some other CSS preprocessor that isn't familiar to me. I started using Sass about three years ago, though I hardly take advantage of all it can do. I have a feeling, I'm not the only one.

There are plenty of advanced topics I want to get into, but I don't want to leave anyone out (especially me) who doesn't have a good grasp of the basics yet. With that in mind I thought I'd start at the very beginning and assume you've never used Sass or any other CSS preprocessor.

If you already work with Sass, I'll do my best to uncover a few details you might not know and at some point this series should catch up with your knowledge and skills. With that out of the way, lets talk about what a preprocessor is and why you'd want to use one.

What is a CSS Preprocessor and Why Use One?

One of the original goals of CSS was that it would be easy to learn. To help with that goal the writers of CSS have generally shied away from adding features that might make the language more intimidating to learn, even if those features would be useful for more advanced CSS authors.

Enter preprocessors. CSS preprocessors are CSS-like languages with additional features. You write your code in the preprocessed language and you use whatever features you find helpful. When compiled your preprocessed code is converted into regular CSS that can be read by browsers.

One nice thing about Sass is the CSS code you currently write is valid Sass code. Once you have Sass installed and set up you can write CSS like you always do and pick and choose the additional features one at a time to incorporate into your code.

Some of those features and coincidentally some of what the posts in this series will eventually cover include:

Nesting — which makes your code easier to read and maintain.
Variables — so you can change a value once and have it update across the site.
Data Types and Operations — to do things like set the width of one column to always be half the width of another column.
@-Rules and Directives — for things like importing one Sass file into another and for extending the language.
Mixins to allow you to define styles that can be re-used throughout the stylesheet.
Control Directives — to add programming logic to your codebase.

There are also several libraries and frameworks available that make things like creating sprites or adding vendor prefixes easy and mostly pain free.

I have to admit when I first heard about Sass and other CSS preprocessors, I was skeptical. I was writing CSS fine and didn't think I needed to learn a new language to write what I already knew.

However, CSS stylesheets have become larger and more complex, even on smaller sites, and as they do the code become more difficult to maintain. The additional features Sass or any CSS preprocessor brings can help make your CSS easier to write and maintain. Sass allows you to write cleaner code that can do more.

Is Sass a Programming Language?

Because it adds some features common to programming languages you may wonder if Sass is a programming language. I'm probably not the best person to ask, since I'm not a programmer, but I'll do my best to answer.

It's certainly not a full fledged programming language though it does add features like variables and control directives (if, while, for) to CSS.

I think it's more properly classified as a scripting language. Sass adds logic to CSS and offers enough programming features for what we need it to do, but I don't think anyone would classify it as a programming language, which is good since that makes it easier to learn.

I guess you can call it a programming language for designers. It gives us the ability to add logic and control to CSS and offers some of the core concepts of programming languages without too much to overwhelm us.

And again the CSS you already write is valid Sass code (using the .scss syntax). You can start how I did and make use of nesting and variables, which are both easy to learn and from there make use of new features as you need or want. You're also welcome to ignore any feature you prefer not to use.

Basic installation and Syntax

Installing Sass is pretty easy. If I can do it, you can too. Sass is a Ruby Gem, which means you have to install Ruby first. If you're on a Mac, you're in luck. Ruby is already installed with OS X. Windows and Linux users will need to install Ruby first and then install Sass.

If you're running Windows you can download an installer here and if you're running Linux you can install Ruby in a variety of ways, depending on your needs and platform

Once Ruby is installed on your system open up the command line and run the following command to install Sass.

1	gem install sass

1	sudo gem install sass

followed by you admin password in the latter case.

If you prefer to stay away from the command line entirely you can install one of several apps that will set up Sass for you. I use and recommend CodeKit, but there are other options both free and paid, which you can find on the install page on the Sass website. If you are a command line person you can type sass --help for the complete documentation.

Zell Liew recently published a good tutorial to help you get over your fears and allergies to the command line if you do want to give it a try.

For the rest of this series I'm going to assume you have Sass up and running whether that means using the command line or an app like CodeKit.

Compiling Sass

If, like me, you decide to use an app to handle everything, you'll want to check the documentation for the specific app to set things up to your liking. Odds are the default will be pretty good, but you can change a few things in how Sass outputs to CSS. I'll get to the different ways next week.

To work with Sass in CodeKit (which also compiles other languages by the way), I drag my project folder into it, which lets CodeKit know to keep an eye on that folder and update the CSS when I make changes to the Sass file. I'm guessing other apps will work similarly.

Before Sass I would set up a project file with an index.html (or .php) file and directories for my CSS and Javascript files, among others. Inside the css folder would be my style.css file.

Now, using Sass, I set up an additional scss folder that's a sibling to the css folder. Instead of writing in style.css, I create style.scss in the scss folder and let CodeKit, create and write to the style.css file when I make changes.

Alternatively if you want to use the command line you'll run

1	sass style.scss style.css

to create the original css file and then

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

to watch for changes to the .scss file and update the css file. You'll want to adjust the paths to the files (when using either app or command line) depending on your directory structure.

Again, if you do prefer the command line, I'll point you to a couple more articles from Zell about setting up projects using Gulp. He uses Sass as an example throughout both articles.

I'll pick things up from here next week.

Closing Thoughts

The main advantage to using any preprocessor is that you get more features to work with than are built in to the native language. The features allow you to write code that is easier to write as well as easier to maintain later.

Installation can be a scary word, but I promise installing Sass is easy and there are a number of tools that will do the work for you.

Next week I'll continue with introduction to Sass, hence the part 1 at the end of this post. I'll show you a quick example along with the different ways Sass can output CSS when compiling. In the weeks that follow, we'll get to some of the features that make Sass something you'll want to use.

Download a free sample from my book Design Fundamentals.

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