“Scalable and Modular Architecture for CSS” – or SMACSS to its friends – is not a framework. It doesn’t force you into working a certain way, and it doesn’t have any dependencies. If something doesn’t sit right with you or your team, leave it out. It’s a set of what Jonathan considers to be best practices, but of course there exists no singular authority on CSS and the organisation thereof, which he himself acknowledges by describing SMACSS as “an evolving guide to CSS architecture for sites small and large”.

We haven’t chosen to use everything set out in the book, but the best thing about SMACSS is that you don’t have to – no one aspect of the set of guidelines is heavily reliant on any other, so you can pick and choose the bits that suit you best.

The Good.

SMACSS promotes a well thought out structure for your styles, neatly dividing your base styles, layouts, and modules. That said, it doesn’t rigidly force you into Jonathan’s way of working. The main idea here is that you define the smallest elements in your design first, making sure to consolidate styles where you can so you end up with a consistent set of components. Building our component library saw me poring over this entire site, and identifying each individual module in all of the content on all of the pages. With that master list of components, I wrote the HTML and CSS necessary to recreate these elements true to their original design, but this time I used SMACSS.

We’ve cherry-picked the bits that we think make most sense for the way we work, leaning heavily on the chapter that defines Depth of Applicability, which is using as few elements as possible per selector. The clever thing about a shallow Depth of Applicability, coupled with using classes – not element names – for your selectors is that you are practically guaranteed that your styles won’t be overridden elsewhere in your stylesheet. Further to that, you have complete element independence - want to style a <dl> like a <ul>? Just switch the elements in your HTML and it should work! This is – of course – a Good Thing™.

The Bad.

Having written CSS for around eight years now, I’ve grown comfortable to a certain way of writing styles and building sites. SMACSS requires a way of thinking that seems entirely counter-intuitive at times.

I’ve also seen proponents of this method happily using non-semantic classes such as .left and .red. The rationale behind these decisions seems to be that between redesigns of a site, the markup is never going to stay the same – which is true – but SMACSS is also perfectly suited to helping you with ongoing maintenance. Who hasn’t launched a site that the client has wanted changing soon after?

It’s entirely possible to employ SMACSS while still avoiding non-semantic classes in your markup. The problem here is what is usually the case with bad development; lazy developers. SMACSS requires such a radical change to the way you think about writing CSS, that you can easily think that undoing years of best practice is the right thing to do. All it takes is a little thought, and perhaps some discussion with another developer if you get stuck. There’s always a better way to write an appropriate class for an element than describing its appearance.

The Fugly.

It can very quickly bloat your HTML – this is a side-effect of the Depth of Applicability I previously mentioned. It appears to be a necessary evil, but an evil nonetheless. For example:

For me, using SMACSS has been a challenging experience at times, but also has shown me that there are other ways of thinking about how to approach styling a page when approaching a build. The great thing about CSS is its flexibility, as SMACSS demonstrates very well. There are things I disagree with, but then there are things that I know make perfect sense. I’m currently employing it in a Phonegap-powered iOS app, where user interface elements need to be granular enough to be dropped anywhere in a design and still maintain their exact design and state-behavior. It’s at times like that when I realise that perhaps an old developer like me does need a kick up the arse on occasion, or I might forget that the one thing I love most about building websites is how it affords me the opportunity to constantly learn.

So what next? 

But what about Specialmoves as a whole? Well, we’re still experimenting and finding out what works for us, and what doesn’t fit the way we build sites. As we continue to explore what SMACSS has to offer, we’ll be updating our front end coding standards, and once we relaunch this site we’ll know how we can take this forward and offer our clients the same benefits it has given us.

Now that we’re familiar with the techniques we'll be investigating how this affects our responsive design workflow, and how SMACSS can also be used within HTML5 application development. I’ll no doubt be following up with another post tackling those very topics in future. Follow @Specialmoves on Twitter if you want to be kept up to date as we post new articles!

---

Jonic is a Front End Developer at Specialmoves, having just moved to London from York. Apparently they have the Internet in the North, as well. @jonic

Follow us on Twitter @specialmoves