Sass, wat?
Yet another introduction to Sass.
When I first heard of the term “Sass”, I thought it was some new fancy way to say Sexy Ass but I was disappointed when it turned out to be Syntactically Awesome Style Sheets. I wanted to try it out but the horror of setting up ruby on my silly windows machine kept me from doing that. So, instead of Sass, I went for LESS (yet, another CSS pre-processor) overall experience wasn’t that bad but it lacked, somehow. Therefore after a few months playing with LESS, I switched to Sass and I haven’t looked back since.
It’s okay. If you haven’t heard the name Sass before, it doesn’t mean you have fallen behind. It is simply a preprocessor that extends the basic functionality of plain CSS and increases your productivity exponentially. Writing Sass is similar as writing plain css (lets just stop writing it in all caps, its awkward), and any valid css is also valid sass, too.
So, what makes sass superior over normal styling? You still get the work done via normal css then why even bother? Mm. Better efficiency and faster workflow while keeping the simplicity, scalability and modularity among your style.
Okay, enough bullock. Show me the codezz?
Check out this little example that intends to write spacing and padding helper classes:
The tiny above example compiles into this much of css pile.
If I have your attention now, let see how easily your machine can be set up for some sassy sauce.
For instance, if you’re fortunate enough to own a mac, open your terminal and write this:
gem install compass
Since sass needs ruby to be compiled and it comes preinstalled with a mac so tada~~ your machine is all set for some action.
For ubuntu users:
As far as windows *coughgetabetteroscough* users are concern, follow the instructions below:
- Download suitable ruby installer from here.
- Install ruby, add the bin to path variable.
- Execute the get install compass from command prompt or any shell you’ve got.
So, what Sass really offers?
To put it simply, whatever the hell css doesn’t… yet. Like:
- Variables
- Nesting
- Partials
- Mixins
- Inheritance
- Operators
- Control Directives
- Functions
And much more.
Before we dig deep into aforementioned sprinkles of sass, lets clear a tiny confusion most of the new comers feel; what’s up with sass and scss?
Its just syntax. If you’re a ruby hipster, go for sass or else choose scss for the love of braces.
Variables
This won’t be a new concept for those who has a very little experience with programming. To put it simply, a variable is a way to store information that you’d be reusing over and over again throughout your code.
Lets say you’re using some cool shade of red in your application, later your client’s wife doesn’t like the shade, and then you’re forced the change the colour, what you’d do if you’re using plain css? Replacing all the occurrences of colour with the updated version? Well, sass reduces all this effort with variables. All you have to do is to declare a variable. You can store things like colours, fonts, or any css value you think you’d reuse. Sass uses the $ symbol to make something a variable.
For example:
Nesting
With appropriate nesting, you’d encapsulate your styles better. And lets accept the fact nesting in css is quite ugly and hard to maintain.
For instance, take this css snippet:
This can easily be done with the following scss:
This is a great way to organise your css and make it more friendly. And it is more easy to manage; for example, lets say if you want to change nav to some other tag, you don’t have to update a zillion time.
Partials
You don’t want all your styles into one huge-ass file. Do you? NO. You don’t. So partials make your life easy if you want to break your styles in relatively smaller chunks of scss thus moaar modularity.
Partials can be defined as according to the official sass guide:
You can create partial Sass files that contain little snippets of CSS that you can include in other Sass files. This is a great way to modularize your CSS and help keep things easier to maintain. A partial is simply a Sass file named with a leading underscore. You might name it something like _partial.scss. The underscore lets Sass know that the file is only a partial file and that it should not be generated into a CSS file. Sass partials are used with the @import directive.
Mixins
Okay, that’s where shit gets a bit serious. Since we’re talking a lot about reusability, lets reuse the most common example you’d find on internet for mixins:
The above example would result in the following css:
So what’s this schlock, actually? Sometimes, css is pretty shitty to write. There are way too many vendors that exist in cssverse. Everybody hates them, so instead of writing them over and over again, you can wrap up all the vendor properties in a mixin and reuse the shit out of it. In the above example we used @mixin directive and named it border-radius, we’re also using a variable named $radius to pass the value of border-radius property whatever we want. After you create your mixin, you can use it with @include followed by the name of the mixin.
Inheritance
Again, if you’re from even a little bit of programming background, inheritance is nothing new for you. If you want to keep your code DRY (Not the opposite of wet, It’s don’t repeat yourself) you may want to extend one feature by including some attributes of another one. This is one of the most useful features of sass. It’s done via using @extend directive. That helps you in sharing a set of css properties from one selector to another. We all have used bootstrap alert in our not so distant past, lets write some sass to obtain something like that with sass’s extend feature:
The above example compiles into:
Pretty self explanatory how easily you can extend one selectors properties into the another and by this you can avoid typing multiple class names.
Operators
Everybody loved maths. No? In case you actually did, there’s a good news for you that sass supports handful of mathematical operators like +, -, /, * and %.
You can use all aforementioned to calculate heights, widths, paddings, your monthly income or whatever the hell you want within your stylesheets.
Lets see how easy it makes your life, this:
turns into:
Viola!
Control Directives
Now, comes the hard part. You may not use these fancy control directives (@if, @for, @each & @while) in your normal, everyday stylesheets, but they are very handy if you’re writing a library or some kind of framework. They are first thing you’d want to learn if you’re willing to write some advance level sassy shiz.
What they do, actually? Mm. Lets just say; they direct the flow of your functions and mixins providing you a finite control over decision making.
@if is the simplest of all, it takes an expression and process its block of style if the provided expression returns anything other than false.
In the above example, the $expression is explicitly true so it’ll render the foo class; if it were otherwise, it would not have been emitted anything while compiling to css.
@for is a looping directive; if you’ve no idea what the heck a loop is; it repeats its body unless it fulfils the provided condition.
The @for directive comes with two flavours.
- @foo $var from <start> through <end>
- @foo $var from <start> to <end>
There’s a very tiny but noticeable difference between the two of them, lets say <start> has value 1 and <end> has 5, the through version iterates through 1, 2, 3, 4, 5. It includes the <end> while on the other hand, to version doesn’t include the <end> value and only iterates till it.
For a very minimal example:
And it compiles into:
@each is the distant cousin of @for, but instead of iterating between <start> and <end> points, it iterates through either a collection or list.
For example:
In the above example, we declared a collection and then iterate through every item to generate a specific class according to the current value. This will convert into:
Very neat and handy when it comes to writing helper classes.
@while is quite closer to @for than @each. It takes an expression(well, duh?!) and repeatedly emits the nested block of styles until the statement evaluates to false as shown below:
Above example compiles into:
Control directives are Nitrous Oxide boost to your mixins and functions. But as they say in most of the movies:
With great power comes great responsibility
You don’t want to ruin your precious code with redundant styles. So, use wisely.
Functions
Functions and mixins are like cousins who are in some sort of complicated incest relationship. (Ew!) But really, they’re quite similar to each other the only prominent difference between mixins and functions is that latter one returns one value that can be of any Sass’s datatypes (number, string, colour, boolean or list).
Why would I even need them then? Readability & DRY.
Lets consider the following function:
This is very simple function that’d add the two values provided via its parameters and return as single value.
Before getting ahead of yourself and writing your own functions for everything, you may want to go through the list of build functions Sass provides out of the box.
Final words
As one could say,
CSS is the ugly, buck toothed girl your parents want you to marry. Sass is the fairy godmother who swoops in and with one sweep of the wand, turns her into a total babe.
Perhaps,
