Skip to content

Review: Sass for Web Designers

The other day I sped through A Book Apart’s latest: Sass for Web Designers by the most excellent Dan Cederholm. The book is a great introduction to Sass and its benefits. Dan is particularly at good easing the reader into Sass, reassuring them that it’s not as scary as it seems, and showing how it can be very useful.

I went through the book quite quickly because some bits are already familiar to me. I’ve been using Sass for a while now, so the chapters on setting up and workflow were just nice reminders of the different ways of doing things. I initially resisted using it, for some of the same reasons mentioned in Dan’s book, but now I’m definitely a convert and wouldn’t go back to regular CSS authoring.

Namespace Nesting

One new thing I picked up was that Sass lets you nest name-spaced properties:

.funky {
    font: {
        family: fantasy;
        size: 30em;
        weight: bold;
    }
}

I’m not sure how practically useful that is, but it’s interesting, and makes me think I should dig through the docs again and see what else I’m missing.

CSS Style, Frameworks, and Methodologies

There are a few bits in the book that didn’t quite sit right with me, though. After a bit of thinking about it, I realised that it comes down to my love of SMACSS, Jonathan Snook’s Scalable and Modular Architecture for CSS.

Dan’s book is about Sass, not about CSS authoring philosophies (like SMACSS, or BEM, or OOCS), so discussing methodologies is outside of the scope of the book. However, I couldn’t help flinching when I saw IDs being used as selectors (#logo), deep nested selectors (“header[role="banner"] #logo img”), and over-qualified selectors (section.main).

@extend

The other bit of Dan’s book that really got me thinking was the section in Chapter 3 on Sass’s @extend directive. Dan gives the great example of using @extend to simplify the CSS for two buttons that are identical except for one CSS rule.

“Instead of littering the markup with extra classes to handle those small exceptions, we can use Sass’s @extend function to “chain together” styles that are shared amongst multiple selectors.”

My worry here is that more complicated examples can start tying things together too much. As the complexity of the CSS increases, the rules that use @extend become too tightly linked to each other. In the preprocessor section of the SMACSS site (members only section, sorry!) Jonathan says:

I recognize that it begins to feel like classitis where multiple (seemingly unnecessary) classes are being added to the HTML. However, these classes aren’t unnecessary. They clarify intent and increase the semantics of the element in question.

I come down on the SMACSS side of this. I prefer adding an extra class or two in the HTML and keeping my CSS as loose as possible.

Conclusion

Dan’s book is an excellent introduction to Sass, and I highly recommend it for any who’s thinking of taking the plunge into CSS pre-processors: his book should convince you that it’s not as difficult to get into as it looks, and that it will make your job easier. The book isn’t strong on methodology, so ideally should be read alongside something like SMACSS to get the most out of it.