Beginner’s Guide To Sass Basics

Beginner’s Guide To Sass Basics

So now that you’ve finally decided to learn some Sass basics, and finally took a bold step forward in digging out my site, let’s first introduce you to what Sass is and all it’s goodies.

SASS – Syntactically Awesome Style Sheets

Yeah. Mouthful. And first time I read it was “synthetically” style sheets. My bad, I guess. Basically, Sass is a preprocessor that introduced so much goodies to the plain ol’ CSS, that I’m pretty sure I’m never going back. Basically it’s to the CSS what Typescript Coffeescript (Kudos to Redditor Myrad for correcting me here) is to JavaScript. Sort of. All right, let’s get down to it.

I am gonna list and explain most of what it does here, and then we’ll move on to individual “lessons” that’ll go in depth and explain everything.
So, here’s what Sass brings to the table:

  1. Introduction
  2. Preprocessing
  3. Variables
  4. Nesting
  5. Partials
  6. Imports
  7. Mixins
  8. Inheritance
  9. Operators

Introduction

Sass logo

The Sass in it’s basic form is in my honest opinion confusing.

Sass has two different syntax, so to speak. Original (Sass) was brought into existence back in 2006, Hampton Catlin, and just like his other project (HAML) was built for Ruby on Rails, so was Sass. Basically, they both shared the same syntax that didn’t include any brackets. Kinda confusing when you look at CSS, really. Here’s an example:

I had experience with HAML, YAML, Stylus and other similar syntax, so this was not really too confusing, but still, when we came down to operators, mixins, all that didn’t really float my boat anymore. And it was a little hard for me to get used to, as I didn’t have to use ; to end the code anymore! Then came Sass version 3, and SCSS syntax was introduced, which is pretty much just extension to CSS, bringing in all the power of Sass to it! Literally, everything you write in CSS is a valid SCSS as well! Obligatory example:

See? Just like CSS. All righty, moving on.

Preprocessing

This is the gist of it. CSS on it’s own is interesting, but as your stylesheets are getting piled up and fat with monstrous code… You need a way to whip monstrous code into shape, right? Sass allows you to use a lot of features (see the list a bit above? Everything under point 2). Of course, in order for it to actually work, you need to install Ruby on your machine, or if you’re into GUI Sass compilers, Koala (Windows, Linux and Mac supported) is excellent and totally free. You can also go through my Gulp tutorials and setup a nice tooling chain to get you up and running in no time!

In our examples here, we won’t get much into the gulp (as I have it explained already), we’ll go Ruby-way here. Here’s a nice guide on how to install Ruby on your machine.

Cool! Off to those Sass basics! In the individual tuts that are coming I’m gonna explain how to setup Ruby to process Sass. 🙂

Variables

Variables in Sass are quite the same thing as in any other languages… They store info to use later on in different functions. In these reusable variables you can store anything, really, like other CSS values, colors, font stacks and so on. We use $ here to declare a variable (if you are familiar with PHP, you’re right at your home!). Example:

Once Sass is processed, the variables will resolve in exactly this:

One important note to take here is that variables won’t be processed into the actual code. The $primary-font and $body-background are just for your Sassy usage.

nesting

This is my crush. This is that gal I wanted to take home after every night out. First, let’s have a look real quick at HTML. If you open up developer tools in any page, you’ll see a well structured code, nicely indented, you can pretty much see an ordered hierarchy of elements and easily distinguish which “child” elements belong to which “parent” elements. CSS is flat. Really, it is. Not like my type of girls.

Let’s have a look at the example of nesting:

Now those are the curves I like! (laugh, please, this is the best joke I have for tonight) Keep note tho: Folks recommend not to go wild on this feature. If it’s 4 steps in, that’s plenty. Time to rethink what your doing.

All this nice and fancy nesting will result in the end code like this:

Isn’t that what we write for every single project? That very code? :p

Partials

CSS already has a way of importing other stylesheets. Only problem is, every time you do this, you will have your server make another HTTP request. Not great for page speed reviews, right? Well, sass has a same feature, @import, which will pull in the _partial.scss files (note the _) and combine all that nice code into the code where you made the import call and then process it into a single stylesheet. Better!

Say you have a partial with variables, or reset, or any other piece of code. Let’s go with reset example!

Now let’s pull it in!

The resulting, processed and refined single CSS file will look like this:

Mixins

Imagine JavaScript functions. It looks like this, right?

Now, Sass mixins allow you to do the exact same thing: take a piece of “functionality” or “style” and use it elsewhere. This saves countless hours on repetition and copy/paste work. Imagine you have 10 different buttons, but they all have border-radius property set? In case you didn’t know, if you wanna go full-browser compatibility, you gotta add up -webkit, -moz, -ms and ocassionally -o (blaaaaaah) in front of some properties. Like border radius! Let’s save time by introducing mixins!

So by saying @mixins and then later on “calling that function” with @include we can save a lot of space in our editor, right?

Inheritance

This is exactly what it means. Other classes (or IDs, mind you) can extend FULLY another class. This is extremely useful on – again – buttons! For example, let’s say you have an array of buttons in your arsenal, for different occasions, of course. Example (continued from previous):

Last but not the least:

Operators

Math in CSS… witchcraft? In Sass, quite all right and finally welcomed!  Sass has a handful of standard math operators like +, -, *, /, and % ! Very useful for setting widths, for example. Let’s say you have a 1200px wide container. You’d wanna split it into percentage parts for it’s child elements, right?

This is your very first grid, believe it or not. 🙂

sass basics – explained

This is pretty much an overlay of what Sass basics are. I will be adding up individual/partial tutorials on all the stuff explained here soon, my tempo is just 2 (maybe 3) tuts a week, so stay tuned and we’ll learn quite some more of SASS – SYNTACTICALLY AWESOME STYLE SHEETS!

Gulp watch – Transpile Sass to CSS on the fly

Gulp watch – Transpile Sass to CSS on the fly

Gulp watch is the command that will stare without blinking at your files and detect saves upon those files. #stalker-detected

All jokes aside…

This is a serious matter. Imagine if you could only click ctrl+s and have files compiled, transpiled, minified, whatever you wanna do instantly without going back to the terminal and running gulp sass …? Yeap. I know your pain.

First of all… We’re going to continue onward from this tutorial. If you have not already completed it – just do it. (I am not affiliated with Nike in any way)
If you completed it already and have the files on hand… let’s dig right in!

First of all, globals explained

Globals in Node (hence, Gulp as well), or globs as everyone refers to them, are file pattern detection expressions that allow you to mass select certain file types (for example). Simplest example would be *.scss, which will totally select only Scss files we have in certain folder.

Most of the projects, depending on their size, of course, will not require you to know more than 3 or 4 such globs. I personally usually use only the last one in the following list.

  1.  *.sass <- This syntax is the most simple way to select a file, irrelevant on the file’s actual name, and relies on the file’s directory location.
    • Pros: Gives you more control on the sass files that are actually going to be watched/worked with
    • Cons: You’re limited to keep all scss files in one folder. I think it’s oke, but for massive framework builds, who wouldn’t wanna have this directory structure:
      |--sass
      |----mixins
      |----components
      |----variables
      |----vendors

      …list goes on. 🙂
  2. *.+(scss|sass) <- This structure will enable you to watch for multiple extensions/patterns as specified. This specific script can go ahead and watch for file saves on both scss and sass files. You can add up more extensions followed by the | (pipe) symbol.
    • Pros: Gives you more flexibility on the pattern and type of what you wanna glob for
    • Cons: None really
  3. !avoid-me-I-stink.scss <- This syntax that has the ! mark in front will tell the watcher not to include this file. In most of the programming languages the ! means the word not, really, or negation of some sort.
    • Pros: If there are files that shouldn’t be included into the gulp watcher method, for example, this is the way to go
    • Cons: Files’ feelings get hurt, you know, for being left out
  4. **/*.scss <- This is the glob I use the most. It’s an upgraded version of the regular *.scss glob, where it states to search the scss files in the current directory and all sub-directories. This is the one that saves your day.
    • Pros: Having the glob that will look for all file types that are ultimately going to compile to assets in ALL directories and it’s subs is the bread and butter of faster workflow
    • Cons: Careful if you have vendor files. You generally don’t wanna change these and then compile them. (*cough, bootstrap*)

Now that we know of globbing, let’s just quickly expand our sass task from gulpfile.js:

Awesome! Now we can move on and effectively compile all Sass/Scss files in the application/scss directory. Let’s try it out?

I’m gonna add up another file to the scss folder. Let’s call it button.scss, add up random stuff, and let’s run gulp sass command! I’ll open up Atom editor and git bash and take one snapshot to show how it goes:

Sass with multiple files

Awesome! On the left you see that the file is compiled, transpilled, copied into the css folder and all that good stuff we wanted to do.

Enter gulp watch

The general syntax for Gulp watcher is actually surprisingly simple, it’s as plain as:

First parameter in the watch function is which file (or files. #globbingpower) to watch, and then in the next parameter you’ll include an array of tasks to run. Let’s now create a gulp watch task:

Basically, we’re creating a task and letting Gulp know he’s gotta keep an open eye on changes to the application/scss/**/*.scss files. If, in this case, any of the .scss files are changed, run the “sass” task that we already have. Lemme show you how the complete gulpfile.js looks like right now:

Give it a whirl. Type gulp watch in the root experiment directory:

Gulp watch running

All right! We have a file watcher in place! Try changing something in any of the *.scss files we have:

gulp watch executes

Woo-hoo! Congrats are in order, again, you’ve set up your very first file watcher using Gulp! This is quite sufficient to run all of your sass compiling, but we only have one more thing to do here, and that is error handling.

Nobody likes watcher errors, right?

So let’s handle them! First, lemme show you how an error looks like with gulp watcher:

Gulp watch error

Oh snap! Now what? Gulp is helpful enough to let you know what went wrong, but the most annoying thing that actually happened is that our watcher stopped. It just bailed on us… Let’s expand our gulpfile a liiiiiiiitle more to see if we can remedy this, and complete this tut.

First, we gotta tell gulp to watch for errors. Gulp has certain events built in, and they’re handled by adding up .on in the pipe workflow. Example:

Oke. This will tell gulp that on case of error, use the custom function showError that I’m about to spill out for you:

Right! Full gulpfile.js right now:

Let’s run our gulp watcher again, and this time I’ll simulate an error by adding up five exclamation marks (!!!!!) to the end of the code. So gulp watch in the terminal, and now save the file with error:

Gulp watch error handled

And there we go! You’ll notice that the gulp “pipe” didn’t break this time, and watcher didn’t stop! You can examine the error, correct it, write proper scss/css and save, and everything will compile!

that’s all folks…

You now have a functional file watcher that’ll keep an open eye on your files, update your regular CSS files and log any errors it encounter along the way!

Stay tuned, next time we’ll see how to have browser refresh itself on file watch. #magic

Click here to continue with this series