Over the last couple of weeks I have been refactoring the Sass used to create the CSS for my blog. The original Sass for my blog was my first excursion into Sass and persuaded me to choose it over Less. Since it was my first adventure into Sass my knowledge was fresh and I was kind of guessing my way around things. Since exploring Sass in the final quarter of last year I have used it in a handful of client projects at Moov2. Over this period my knowledge of Sass has grown a little so I decided a revisit to my first attempt with Sass for my blog was needed. This post will share some of the changes made and hopefully offer some useful tips.
Research into how others do it!
Sass has become a very popular CSS preprocessor over the last few months with many realising it's potential even though some debate the quality of the output. As a result of this popularity there are many more examples of Sass available that you can learn a great deal from. I always find it useful to see how others are implementing a subject that is relatively unknown to myself to generate ideas and gain a deeper understanding. Over the last couple of months I have been following a framework that has been overhauled using Sass called inuit.css by Harry Roberts. Inuit.css is a library of useful CSS abstractions and objects that has rapidly grown with many contribution and interesting discussions. By following an open source project like inuit.css, I have found it invaluable, gaining a free education to gain a greater understanding on a language or tool I lacked knowledge of.
I use the command line to convert Sass to CSS. That means every time I want to make changes to Sass in a project I open up a command prompt, navigate to the directory and run the
-watch Sass command. Granted thats not too taxing, however doing it all the time can be a bit repetitive. The solution was to include a windows script command that opens a command prompt and sets up the watching of the primary Sass file, which will convert it to CSS when changes occur. For those on OSx or Unix check out the watch.sh command in inuit.css. Although this only solves a tiny headache, I have found it a convenience for getting out of the blocks quickly.
Breaking Things Up
In my first dance with Sass I placed the majority of the Sass code in a well organised file that was easily navigable by using the contents that was placed in comments at the top of the file. Each section in the file would have a comment with the section name (matching one in the contents) with a
$ sign prepended so a common find in the file could get you to each section swiftly. Although it was fairly easy to get to the section you wanted to work on, large projects can cause the file to become large with lots of code.
To combat this and introduce a structure to the Sass I broke the sections into separate files that are puzzled together by the main
.scss file using the @import rule. This approach is used by all the frameworks mentioned in this blog post. The main challenge for this task was to decide how to break things up, something I think only you can judge. I went with three directories, one containing useful mixins and extensions, another containing files that describe abstract classes and then finally a directory with files that describe modules specific to the project user interface. Having an organised structure in place makes it really easy to navigate around the Sass for the project increasing the ability to keep focus on a task.
Nesting is cool, but don't overuse it
This one isn't a Sass specific tip as over nesting is discouraged in vanilla CSS. However nested rules is one of the best features in Sass and it is easy to get carried away with such power. One of the rules I enforced on myself during the refactor was to not nest classes unless there was a strong case for it, an example would be styling
li elements in a list. Doing this meant I put a lot more thought in the naming of the selectors and the structure of the HTML mark up. This actually resulted in the removal of HTML elements which was encouraging, any refactor that results in less code for the same functionality is always an indicator your doing it right. My advice here would be, yes the nested rule is a brilliant feature especially for pseudo classes and media queries, but don't abuse the feature and cause performance issues with the website with in-efficient CSS selectors.
Nested rules are a cool feature, but variables are even better! As a developer, having the ability to define variables in CSS is an amazing feature and extremely powerful. The use of variables promotes the don't repeat yourself (DRY) principle that should be familiar with most developers. Variables do require some thought though, they need to be well named and used appropriately. A good principle to have is if you find yourself putting the same value multiple times, it is probably a good candidate to be a variable. Another candidate is if the value is something that you would likely want to configure (e.g. font family), then using a variable means there is no need to try and find the value in the CSS / Sass files. Instead it should become common knowledge amongst yourself and any other team members to instantly know to check the Sass file that contains the variables. The last candidate for a variable is to provide a more human readable representation of a value, for example colours that aren't already in the CSS colour specification.
During the refactor I used variables when the candidates above arose. In the CSS for my blog there are many instances of margins & paddings that were using magic numbers, a prime candidate for variables. Instead of creating lots of different variables for
0.6em and so on, I created a single variable called
$spacing-unit. I tried to apply the
$spacing-unit to all the padding & margin elements, sometimes using the arithmetic operators with the
$spacing-unit for sparsely used values. What this encouraged was consistent spacing between elements in the design, which was great. Another advantage from the spacing variable was that it forced me to consider whether CSS properties were worthy of having. If the CSS property wasn't contributing to the design & layout then it was deemed unnecessary and removed. Once again, if I was removing code then I was confident that I was moving in the right direction.
I definitely recommend using variables, to get the best out of variables they need to be named coherently and used appropriately.
Do you need a framework or library?
This is a short one that came up during the refactor. In the first Sass attempt I used Bourbon to provide useful mixins, but in the refactor I decided to question if it was worthwhile having. It turned out that I really didn't utilise much of the framework. I went with the decision to remove the dependency and create my own mixins to fulfill the ones I was using from Bourbon. Removing Bourbon reduces the management required to keep the library up to date and also I was deleting a lot of files from the project. You should always have a think, do you actually need this library or framework? What benefit is it providing? Are you using enough of the library for it to be justifiable? Answering these questions will reveal the answer if the framework or library is required.
All the Sass that makes up this blog can be found on Github so feel free to have a look. I have tagged the project before the refactor as