This is an intervention.

CSS is pretty simple. Classes, IDs, elements and pseudo-elements, with style definitions attached to each. Calling it a "language" is a bit of a stretch (though preprocessors like Sass fit the bill).

But let's be honest, for years our stylesheets cascaded right on out to infinity.

Huge files with table-of-contents comments to try to make some sense of it — until a quick fix got pasted down at the bottom. Brittle style definitions relying on tight coupling with HTML structure. Pieces of styles being replicated here and there for different components with similar features, without any way to tell they were related in the CSS.

My stylesheets were like that too, because strategies for writing CSS had barely altered since the days when it was used to change the colors of the scroll bars in Internet Explorer. Luckily, in the past couple of years both CSS architecture and CSS preprocessors came into their own.

SMACSS, or Scalable and Modular Architecture for CSS, was developed by Jonathan Snook, a featured speaker at Drupalcon Portland. I'm really excited to get the opportunity to have Jonathan speak, not only because of my personally well-dog-eared copy of SMACSS, but because Drupal itself is adopting a SMACSS approach to its CSS.

I spoke with Jonathan about sustainable stylesheets and the future of SMACSS. For an even more detailed look, please join me at Jonathan Snook's featured Drupalcon Portland this afternon, Tuesday, May 21 at 4:30 PM.

IB: What's the biggest mistake you see people making when writing CSS?

JS: I think the biggest mistake is thinking of everything in the context of a single page. We're no longer just building sites with a design for a home page and an inside page. We're developing complex systems that need to work in a variety of contexts and we need a development approach that complements that.

IB: What's the biggest "win" you see in using the SMACSS approach? Why should frontend developers change their approach to CSS?

JS: The biggest win is maintainability. The SMACSS methodology makes it easier to build larger projects by breaking things down into smaller components. Like the move from spaghetti code to MVC frameworks on the server side, this separation of concerns on the CSS side improves the process of putting a site or web app together.

IB: In the last part of your book, you talk about how the SMACSS approach fits in to work using a preprocessor like Sass. There have been a lot of developments in Sass in the past year — have they had any positive effects on your use of the SMACSS approach?

JS: With Sass, the introduction of placeholders was a positive step forward. Overall, Sass (and other preprocessors) are a great way to augment — but not replace — the way people write CSS.

IB: What are your thoughts on BEM? Do you see it as compatible with SMACSS?

JS: I see BEM as very compatible. BEM really enforces naming convention, which is a very important concept in SMACSS. They both take a modular approach to site development.

IB: What are you tacking next when it comes to CSS and frontend development? Will there be a "SMACSS Part Two"? Or something else entirely?

JS: I'd love to augment SMACSS with case studies and expand on some of the ideas in the book based on things that come up in the workshops I do. I'd also like to work on a prototyping/site development tool that uses the SMACSS concepts. We had built something like this when I was at Yahoo! that I think many people in the industry would find really useful. Hopefully I can find the time to work on it!

Image credit Flickr user stevensnodgrass. It's spaghetti! (As in code.)

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.