On smaller brochure sites, how your organize your styles isn’t usually a big concern. You get in there, write some CSS, or maybe even some SASS. You compile it all into a single stylesheet with SASS’s production settings, and then you aggregate it to get all the stylesheets from modules into a nice tidy package.
However, when it comes to larger, more complex projects, how you organize your code is a key to efficiency. Not only in how how much time it takes, but also in how much code you write, and how much a browser has to load. This is especially important when you’re working with a team of themers, and when performance is important (seriously, when isn’t it?).
SMACSS (pronounced Smacks) isn’t exactly a new concept. I feel as if the idea behind it actually pre-dates it’s name. Regardless, it was Jonathan Snook that wrote the book on it a couple of years ago, gave it a name, and people started taking notice. The concept is a guide, not a framework, nor a library. You don’t download anything, you don’t run anything from the command line. It is simply a way to organize your code. It stands for Scalable and Modular Architecture for CSS.
If you start with a base theme, especially if that theme is a framework, a lot of the work has already been done for you. Zurb Foundation is a good example of this, or the stripped down Zen 5 theme. If you crack open the sass directory of the Zen sub-theme, you get a good preview of SMACSS in action.
In SMACSS, there are basically 5 different types of rules. Base, Layout, State, Module (which we’ll call Component so it’s not confused with Drupal modules), and Theme rules.
Base Rules - these are base rules that apply to elements and used throughout the site. These are normally HTML elements. So, paragraphs, headlines, lists, etc. are given their styles here that can be used throughout your site. Normalization (making elements look the same in all browsers) - is a part of your base rules.
Layout Rules - these target your template regions. They define widths and positioning of your regions in your pages. So your header, sidebars, main content, footer, etc. These can often be thought of as IDs in the DOM. An item that appears in your layout styles should only appear a maximum of once per page.
Component Rules - these are for the building blocks of your pages. Most of your styles will be written here. They can be Drupal blocks, but not always. Your navigation region’s layout (width & placement) was defined in your layout rules, but how your navigation looks, gets defined here. This is also where you’d style blocks created from views and placed on a page. If using SASS, and if you glance back at the structure of a zen sub-theme, these separate components would each have their own SASS partial, semantically named, so anyone would know where to go to edit the styles for your Recent Content block, or slideshow. These partials will then be combined when compiling.
State Rules - these are rules used for elements that have multiple, well, multiple states. These are often elements that have classes applied or toggled using javascript. These are things like collapsible field groups, or quick tabs. They can also be css pseudo-classes, like div:hover, or a:active. Since SMACSS is only a style guide, I’ve been known to include these rules in my base or component section, depending on where they fit. Some people feel like responsive styles qualify as state rules. I, however, believe that in this day and age, all viewports are equally important, and all styles for that component, or for layout, belong together. It’s much easier to maintain.
Theme Rules - are things like your page background, typography, colors, etc. This is another area I often pass on, except for when I need to override theme elements for different pages. An example of this would be maybe a content-type that has a different style in order to set it apart from the rest of the site. So if your page has a white background - body {background: #fff;} but on blog pages it should be gray, I’d use a theme rule to overwrite my base rule - .node-type-blog {background: #ccc;}
That’s about all there is to it. The more you do it, the more natural it feels. The pros of doing it this way is anyone can open your theme directory and find what they’re looking for. If you have multiple people working on a project, you aren’t getting in each other’s way. And when you do it right, you’re not writing overly specific rules that lead to bloated CSS in your themes.
For more information on SMACSS, go to the SMACSS website.
For more information on using Zen, watch the Acquia webinar on creating responsive websites using zen 5.
