Introduction To Sass

A Practical Introduction To Sass

by Sanjay Poyzer

Hello everybody, I’m going to be doing a practical introduction to Sass, the CSS Preprocessor.

http://sassnotsass.com

First things first, it’s Sass not SASS. Sass doesn’t stand for anything, except maybe making your CSS more Sassy…? Sass makes CSS more Sassy because it’s a preprocessor. Preprocessors make writing code easier. !If it helps, you can think of Sass making CSS more like a real programming language. If that doesn’t help, just think of it as a way to write CSS that’s more cleverer. !On that note, those of you who do program may find this a bit slow, but I want to make sure people who just know CSS get some of the concepts that Sass relies on.

Browsers Don’t Know Sass

Who are you?

heyyyy!

Everything you know about browsers still stands though. They don’t know Sass, so you need to convert what you write with Sass back over to CSS at some point before your page loads. That sounds like a pain, and it actually put me off for ages, but it’s actually super simple to do. I’ll leave that bit to the end though.

Sass is like LESS. But it’s better.

Here’s why - http://css-tricks.com/sass-vs-less/

I’m not going to talk too much about LESS in this talk. LESS serves a similar function, it’s a preprocessor, but most people these days tend to agree Sass is better. If you’re really interested in why, the effable Chris Coyier has done a write up in detail.

Reasons We

1. Variables

2. Mixins

3. Nesting

4. Partials / Imports

5. Extends

6. Operators

So what can we actually do with Sass? Well, at a glance, these are it’s main features. Let’s dive into them one by one.

.sass .scss

.css

Before we do that though, here’s some Sass. It might look a bit scary and weird right now, but hopefully by the end of this it will make complete sense. You’ll notice there are 2 ways to write Sass. Proper Sass and “Sassy CSS”, or .scss. The only difference is that if you go full Sass, you don’t need to write those curly brackets, it’s syntax is recognised through indentations. That’s cool and everything, but I tend to stick with .scss, mainly because all normal CSS is already valid in a .scss file. So I can start a project in CSS, and then decide that actually Sass is going to be useful here, and just copy the code over to a .scss file. Also I kind of find those curly brackets oddly comforting…

1. Variables

.scss .css

So here’s feature #1 - Variables. Variables are a staple of programming in general, but absent from CSS, which is a shame. Especially because there are so many things in your stylesheets that could change at any time. An easy practical example is setting up colors, or fonts as variables. Let’s say you were writing just in CSS and then you wanted to change your site’s colour scheme. You’ve probably used the same colours a bunch of times throughout your site, so it would be a pain to go through and change them all. Ok sure, you *could* find and replace. But this way is cooler.

Sass keeps you DRY

That’s the biggest selling point of Sass. It helps keep you DRY. DRY stands for Don’t Repeat Yourself. It’s good programming practice, and the idea is if you start repeating yourself anywhere, think about if when change instance 1, you also want the second instance to change. In CSS, you can think about that all you want and nothing’s going to change but in Sass you can make those things a Variable. But that’s not all…

2. Mixins

.scss .css

You can also give those variables arguments. Mixins are basically variables that can take arguments. Again, the programmers in the room will know what’s going on here but for everyone else, the brackets are essentially an extra input to the function. So you set up your mixin and say when this is called, output all of this stuff, and every time this happens, replace it with whatever’s in the brackets. It’s pretty powerful for those CSS3 features that need vendor prefixes. It’s best to have a bunch of these mixins set up for all the times you need to tell CSS to do a bunch of stuff, but with a variable in the middle of it. You might already use a CSS framework like Bootstrap. Sass frameworks (Compass is a great one) mostly use the power of mixins to make all this stuff easier to write.

3. Nesting

.scss .css

But not as cool as this. This might be my personal favourite thing that Sass does. It might not be immediately obvious from these examples, but nesting will save you a bunch of typing time. In the example on the left, you’ll see we only needed to type ‘nav’ once.

3. Nesting

.scss HTML

It also saves you thinking time. If you’re anything like me, you’ll spend a lot of time looking at websites using the Element Inspector on the right. Nesting allows you to structure your CSS to reflect the DOM tree laid out in HTML. It’s still the same CSS eventually remember, it’s just easier to read for purpose.

However…Think carefully about specificity.

http://youtu.be/R-BX4N8egEc

After this, go watch Harry Roberts’ talk on Big CSS.

Sass won’t solve all your problems for you though. Think carefully about how specific you want each rule to be. It’s best to try and keep your CSS rules as broad as possible, to apply to the most amount of elements with the least amount of work. So go watch Harry Roberts’ talk on Big CSS. It’s an hour of your time, but really will change the way you write CSS, whether or not you choose to use a preprocessor like Sass. Coming back to Sass, a general rule of thumb with nesting to avoid being over specific is “Don’t nest more than twice.” If you’re nesting more than that, have a think about if there’s actually any purpose to it. Going back to the menu example, you can see it doesn’t completely reflect the HTML, because it doesn’t really need to in this case.

4. Partials / Imports

+

Sass does Partials and Imports way better than normal CSS. In normal CSS, you can break your stylesheets up into smaller, more manageable files and use @import to compile them. However, that compiling happens all on the client side. Each HTTP request slows down the overall speed of your site, but because Sass is processed before it gets anywhere near the browser, you can break your stylesheets up as many times as you want, and it will get compiled into one handy stylesheet.

5. Extends

.scss .css

Extends are pretty simple to understand. Take all the rules applied to this class, and apply them to this class as well. If you take yourself through the process of writing the CSS on the right, you’ll see that you just wouldn’t think to write it like that. What you’d probably end up doing is writing all those rules for those classes individually, which would be boring to write and just be extra code for the computer to process.

Also…Extends help you stay semantic.

https://coderwall.com/p/wixovg

After this, go read “Bootstrap without all the debt”

Extends are a really great way to keep your HTML semantic. Instead of littering your HTML with tonnes of classes like “main-font green big” that could potentially change later on, you can keep all your style rules in your stylesheets! Bootstrap and other bits of copied code gets people into bad practices like this, mainly because out of context, you kind of need those classes in your HTML. But when you’re working on a big site that might be changed a fair bit, you can use extends to keep everything cleaner.

6. Operators (+, -, *, / & %)

.scss .css

Sometimes maths is useful when you’re writing stylesheets. There’s actually now a calc function in normal CSS that acts fairly similar, but that relies on browser support. Using operators in Sass is of course especially powerful because you can use variables like $sidebar-width and then calculate a margin that you know will change when you change that variable. You can also do if functions, and for and while loops. I won’t go into those here though.

Preprocessing, e.g. CoffeScript,

Server-Side, e.g. PHP/Ruby

Client-Side, e.g. HTML, CSS, JS

You. Writing code.

The User.

When you’re doing maths though, or indeed any computation in your code - You need to be mindful of where in the process between you and the user that computation is happening; Where your code runs. So without preprocessors in the mix, you have your front end and your back end; Your server side stuff and your client side. That’s why you can’t use maths in Sass to respond to a user resizing their window for instance, and you can’t set up variables in Sass that change depending on something the user does. It compiles over here, way before any of that stuff happens. You can make your client-side stuff talk to your server side, but you can never get that stuff to talk to preprocessors, because Browsers don’t know Sass.

How to preprocessor?Using ‘Rails? Get the gem.

So by now you’re probably all dying to know how do I actually turn this Sass stuff into CSS that the browser can understand. Well, if you’re using Ruby on Rails, you just install the gem and you don’t need to worry about it ever again. If not, you’ll either have to tell your computer via the command line to watch for changes in the file you’re working on and then compile it.. OR just install a program that does that for you. Here’s some examples. I personally use CodeKit for Mac, and Jerome uses Prepros on his PC. It’s really simple, you just add your project and make sure your app is running while you work. This list is taken from the Sass website, which brings me onto my final slide…

http://sass-lang.com

The Sass website. More information about everything I’ve talked about is on there in the docs, including reference for all the terms. When you start using Sass, you’ll probably need it open in a tab for a bit, but there really isn’t that much to learn and I promise you it will make your life better!