Jonathan Snook - Scalable and Modular Architecture for CSS

Hi, my name is Jonathan Snook. I am a web developer and designer who has been building websites as a hobby since 1994 and as a professional since 1999.

I maintain a blog at Snook.ca where I write tips, tricks and bookmarks on web development. I also speak at conferences and workshops and have been thankful to have been able to travel the world to share what I know.

Ive co-authored two books to date: The Art and Science of CSS (from Sitepoint) and Accelerated DOM Scripting (from Apress). Ive also written for .net magazine, A List Apart, Sitepoint.com, and many more resources online and off.

Having worked on hundreds of web projects, including most recently on the successful Yahoo! Mail redesign, Ive written this book to share my experience with building websites small and large.

Id like to express my deepest gratitude to everybody within the community. Each and every one of you make this a career that I continue to enjoy having. A special thank you to Kitt Hodsden for pushing me to write this and share it with everyone. Lastly, to my boys, Hayden and Lucas, who continue to push me to be a better person.

I have long lost count of how many websites Ive built. You would think after having built a few hundred of them I would have discovered the one true way of doing it. I dont think there is one true way. What I have discovered are techniques that can keep CSS more organized and more structured, leading to code that is easier to build and easier to maintain.

I have been analyzing my process (and the process of those around me) and figuring out how best to structure code for projects on a larger scale. The concepts were vaguely there with the smaller sites that I had worked on but have become more concrete as a result of working on increasingly complex projects. Small sites dont often hit the same pain points as larger sites or working with larger teams; small sites arent as complex and dont change as often. However, what I describe in these pages is an approach that works equally well for sites small and large.

SMACSS (pronounced smacks) is more style guide than rigid framework. There is no library within here for you to download or install. SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS. And really, who isnt building a site with CSS these days?! Feel free to take this in its entirety or use only the parts that work best for you. Or dont use it at all. I understand that this wont be everybodys cup of tea. When it comes to web development, the answer to most questions is it depends.

My thoughts have been compartmentalized around a number of topics related to CSS architecture. Each thought is detailed in its own section. Read the sections in sequence or out of order or pick and choose what seems most relevant to you. Its not 1000 pages of writing; the sections are relatively short and easy to digest.

Now get started and dive in!

Every project needs some organization. Throwing every new style you create onto the end of a single file would make finding things more difficult and would be very confusing for anybody else working on the project. Of course, you likely have some organization in place already. Hopefully, what you read among these pages will highlight what works with your existing process and, if Im lucky, you will see new ways in which you can improve your process.

How do you decide whether to use ID selectors, or class selectors, or any number of selectors that are at your disposal? How do you decide which elements should get the styling magic you wish to bestow upon it? How do you make it easy to understand how your site and your styles are organized?

At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.

There are five types of categories:

1. Base
2. Layout
3. Module
4. State
5. Theme

We often find ourselves mixing styles across each of these categories. If we are more aware of what we are trying to style, we can avoid the complexity that comes from intertwining these rules.

Each category has certain guidelines that apply to it. This somewhat succinct separation allows us to ask ourselves questions during the development process. How are we going to code things and why are we going to code them that way?

Much of the purpose of categorizing things is to codify patternsthings that repeat themselves within our design. Repetition results in less code, easier maintenance, and greater consistency in the user experience. These are all wins. Exceptions to the rule can be advantageous but they should be justified.

Base rules are the defaults. They are almost exclusively single element selectors but it could include attribute selectors, pseudo-class selectors, child selectors or sibling selectors. Essentially, a base style says that wherever this element is on the page, it should look like this.

Examples of Base Styles

Layout rules divide the page into sections. Layouts hold one or more modules together.

Modules are the reusable, modular parts of our design. They are the callouts, the sidebar sections, the product lists and so on.

State rules are ways to describe how our modules or layouts will look when in a particular state. Is it hidden or expanded? Is it active or inactive? They are about describing how a module or layout looks on screens that are smaller or bigger. They are also about describing how a module might look in different views like the home page or the inside page.

Finally, Theme rules are similar to state rules in that they describe how modules or layouts might look. Most sites dont require a layer of theming but it is good to be aware of it.

By separating rules into the five categories, naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.

I like to use a prefix to differentiate between Layout, State, and Module rules. For Layout, I use l- but layout- would work just as well. Using prefixes like grid- also provide enough clarity to separate layout styles from other styles. For State rules, I like is- as in is-hidden or is-collapsed. This helps describe things in a very readable way.

Modules are going to be the bulk of any project. As a result, having every module start with a prefix like .module- would be needlessly verbose. Modules just use the name of the module itself.

Example classes

Related elements within a module use the base name as a prefix. On this site, code examples use .exm and the captions use .exm-caption. I can instantly look at the caption class and understand that it is related to the code examples and where I can find the styles for that.