Last week at work I ran into an issue when I inherited a project whose CSS left a bit to be desired. I had to apply CSS styles on a specific Wordpress page, but because the other CSS styles were overly broad, I had to use very specific selectors.
Faced with either untangling and rewriting the CSS or adding very specific selectors, I opted for the latter because of the scope of the project as well as time constraints. While writing the CSS, I became increasingly annoyed with writing CSS similar to this:
It’s not terrible, but it’s ugly to write and involves a lot of copying and pasting. Not fun.
A couple days later I began a new project and decided to try out SCSS.
SCSS (Sassy CSS) is a superset of CSS. This means any CSS is valid SCSS, and any SCSS you write will translate directly into valid CSS. Essentially just it extends the language by adding some new syntactical features.
While I’m used to having to fiddle with software to make it work (I use GNU/Linux as my primary OS), I would really rather just have it work right out of the box. Much to my surprise and enjoyment, SCSS works right out of the box.
If you have Ruby installed, all you need to do is type
gem install sass into your command prompt. (Note the spelling: sass not scss.)
That’s it. No fiddling. No BS.
Then, in order to convert your SCSS to CSS as you type, simply type
sass --watch INPUT.scss:OUTPUT.scss. If you’re wondering,
OUTPUT.css can be any name you want, just note the order—SCSS:CSS.
Perhaps the coolest feature of SCSS is nested styles. Nested styles translate directly to repetitive selectors (like in the code snippet above), and it also introduces the idea of “scope”. So, for example, my example from earlier rewritten in SCSS would be:
It saved me from typing
body.page-id-3398 multiple times, which is a huge plus—and that’s only the most basic part of SCSS.
SCSS also has mixins, which are reusable code snippets. Consider this:
In SCSS, that could be written as:
If you have a snippet you want to use often, mixins help create very dry code.
(Side note: you can also use
@extend, which behaves in similarly, but I don’t understand that much yet so I’m intentionally leaving it out.)
Another great part would be SCSS’
@import feature. SCSS’
@import behaves different than CSS’, and is in many ways better.
Because SCSS is a preprocessor, you don’t load the stylesheets when the page is being rendered like you do with vanilla CSS’
@import. Rather, all the styles are imported when the SCSS is being processed.
@import will directly import the entire compiled SCSS into the file which calls it—great for modular code.
Most programming languages have what are called variables. These could be thought of as (granted, this is an oversimplification) little boxes that hold values. When you use the variable, you’re just using what’s inside the box.
SCSS isn’t a programming language, but it uses variables as well. One of the primary use cases of SCSS’ variables is to hold color codes.
Most of us have, at one time or another, been writing CSS and had to try to remember the hex or rgba value of a specific color. If you have two similar colors, this becomes increasingly difficult. With SCSS’ variables, you can just give a color a descriptive name and use that instead. For example:
Variables, mixins, and includes are just a portion of what SCSS can do. I’d recommend you check out the language specifications on SASS’ website—you’ll never want to write plain CSS again.