A practical introduction to Sass.

1. A Practical
Introduction To Sass
by Sanjay Poyzer
Hello everybody, I’m going to be doing a practical introduction to Sass, the CSS Preprocessor.

2. 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.

3. Browsers Don’t Know
Sass
heyyyy!
Who are you?
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.

4. 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.

5. 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.

6. .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…

7. .scss
.css
1. Variables
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.

8. 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…

9. .scss
.css
2. Mixins
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.

10. .scss
.css
3. Nesting
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.

11. .scss
HTML
3. Nesting
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.

12. However…
Think carefully about specificity.
After this, go watch Harry Roberts’ talk on Big CSS.
http://youtu.be/R-BX4N8egEc
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.

13. +
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.

14. .scss
.css
5. Extends
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.

15. Also…
Extends help you stay semantic.
After this, go read “Bootstrap without all the debt”
https://coderwall.com/p/wixovg
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.

16. .scss
.css
6. Operators (+, -, *, / & %)
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.

17. You. Writing code.
Preprocessing, e.g. CoffeScript,
Server-Side, e.g. PHP/Ruby
Client-Side, e.g. HTML, CSS, JS
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.

18. 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…

19. 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!