Sass: the powerful professional grade CSS extension language is a popular tool. But are you using it properly? Here, we share some common Sass pitfalls and how to avoid them.
01. Nesting too deep
While it's tempting to translate your nested HTML structure to Sass, it creates overly specific selectors that will hurt you in the long run. As per the 'inception rule (opens in new tab)': don’t nest more than four levels deep.
02. Using mixins instead of extend
If you find yourself using mixins that don't take arguments or a @content block, you're adding code bloat to your CSS. You will be repeating code in your compiled CSS. As a rule of thumb, use the @extend directive (opens in new tab) when there's nothing dynamic about your mixin.
03. Always using vendor prefixed mixins
One of the great things about the Sass ecosystem is the large number of frameworks and extensions – for instance those designed to help with CSS3 vendor prefixed properties. Don't resort to these by default though: the border-radius property for instance hasn't needed prefixing for a while, so don't bloat your code by continuing to use a mixin for this.
04. Committing CSS files to version control
Commit your source files, which in case of Sass means your .sass or .scss files, and not your compiled .css files. It will only tempt others to make changes in the wrong files, and having those changes overwritten later.
05. Not petting a kitten
Sass is licensed under the MIT License, which makes petting a kitten more a suggestion than an actual requirement. The same goes for paying Catlin a compliment or buying Weizenbaum some jelly beans, although they would appreciate it. Seriously, it's in the author’s section of the ReadMe (opens in new tab).
Words: Roy Tomeij (opens in new tab)
Roy Tomeij is a Dutch frontend architect, Sass evangelist, trainer and speaker. He's writing a course about "turning Sass up to eleven" at advancedsass.com (opens in new tab). This article originally appeared in net magazine (opens in new tab) issue 257.