DON’T MISS OUT

Why I Fell in Love with the Sass CSS3 Extension, And You Will Too!

In some ways I’ve always been a traditionalist. I like writing my code from scratch, without preprocessors and frameworks. I feel like I have more control over what I’m doing. Recently, however, I finally took a proper look at Sass – the CSS3 extension – and I have to say that I’ve kind of fallen in love with it!

What is Sass?

Sass is a CSS3 extension, which is a CSS extension that runs using Ruby. It’s a super easy install, and once you’re up and running you can start using SASS on any project, whether Ruby based or not.

Sass really extends the functionality of CSS, and gives you a lot of control in writing flexible stylesheets. The Sass files you write are translated into standard CSS as you work. You can use partial files, variables, nest your selectors, easily reuse CSS, or inherit styles.

Some basic uses of Sass in a project

There are two different syntaxes for Sass. I’m working using the newer SCSS syntax, which I find is far easier to get used to than the older indented SASS format. SCSS pretty much expands upon existing CSS syntax, rather than changing it, so it’s very accessible. If you know CSS, you’ll probably be able to work out SCSS pretty easily simply by looking at some code.

In my project, I’ll have a “css” folder, and inside that I’ll also have a “sass” folder. Running Sass from the command line, the .scss files I write will be automatically collated into CSS. So, I’ll start with a “style.scss” file within the sass folder, and that will create a “style.css” file.

Nesting your code

Although I talked a while back about trying to avoid repetition with a class based approach to CSS, it’s still an annoying part of code. Sass removes much of that annoyance through nesting. e.g. I want to target styles on various aspects of an HTML structure;

The code is simpler, more elegant to read and understand, and will be collated into the appropriate CSS.

Easy partials

I can create partial .scss files to import into my main Sass file easily. I just create an additional file in the sass folder, e.g. “_partial.scss”. Then in my main “style.scss” file I add;

@import "partial";

I can add this import command anywhere within the master sheet.

This is obviously very similar to the standard @import in CSS. The different being that because the Sass file automatically collates into a single CSS which you *then* deploy, there aren’t additional http requests to bring in additional stylesheets.

Mixins

I really like mixins. Mixins allow you to create a chunk of CSS, which you can then target at any element within your .scss code. This is really useful for styling that you commonly apply to different elements of a page.

e.g. I have some styling that I know I’m going to apply regularly to blocks of text, and so I create a mixin:

Mixins make it a breeze to have styling snippets that can be easily re-used.

Is there a down side?

From a workflow point of view, I don’t see one. I’ve always been confident that I’m a really fast coder, which is probably one of the reasons I didn’t adopt Sass early. But Sass has made my implementation of CSS much much faster, and with little to no learning curve.

The only downside is in file efficiency. The collated final CSS file that you deploy can sometimes become a little over complex. It’s not enough to have a significant impact (and Sass does well at minifying the file), but it is going to make life difficult for someone needing to make direct CSS changes.

On balance, however, I can’t see any strong reason not to use Sass.

Give Sass a try

This isn’t intended to be a comprehensive overview of all of Sass functionality, just a brief introduction. I haven’t been working with Sass for that long, and I’m already discovering more and more additional functionality.

It’s incredibly easy to install and start using, and the development of the .scss syntax means that it’s far more accessible to anyone who’s familiar and comfortable with standard CSS. I’ve found it a complete joy to work with.

5 COMMENTS

Comment Policy

Please join the conversation! We like long and thoughtful communication.
Abrupt comments and gibberish will not be approved. Please, only use your real name, not your business name or keywords. We rarely allow links in your comment.
Finally, please use your favorite personal social media profile for the website field.

Yeah, LESS is definitely another legitimate option. What’ll be interesting is seeing the long term “market penetration” and how that impacts developers. A few years ago there was no real consensus on Javascript libraries, and now jQuery has a pretty dominant position. I can see a similar consolidation happening when it comes to CSS preprocessors, particularly as the support for the more advanced capabilities of CSS3 becomes more widespread.