With the focus being on the latest and greatest CSS3 snippet to replicate something we’ve done with images for years, it’s rare to read a solid discussion on the fundamentals of CSS. It was completely refreshing to read just that in Scalable and Modular Architecture for CSS (SMACSS) by Jonathan Snook.
I’ve had a long time respect for Jonathan. I remember reading his articles as I was teaching myself CSS, he was then just as much as he is now involved in the community and sharing his knowledge. I found his advice not only to be sound, but also referencing stuff he was currently working on. For one reason or another, that’s really rare with the more “Web famous” designers/developers out there, and I really like that.
The book is preempted on the site like so:
I’ve 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. What I’ve found is a process that works equally well for sites small and large.
Learn how to structure your CSS to allow for flexibility and maintainability as your project and your team grows.
A bit later, the premise is wrapped up with:
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 isn’t building a site with CSS these days?!
Refreshing. Much of what we read about lately is the latest CSS framework or boilerplate whatchamacallit. Fact of the matter is, while those tools can be useful, they’re only part of the solution. It’s up to you to fulfill the rest with your own know-how, and you need a plan of action.
Scalable and Modular Architecture for CSS
The book is broken down into easily digestible chapters.
- Four Types of CSS Rules
- Themes and Typography
- Depth of Applicability
- Selector Performance
- State Representation
- HTML5 and SMACSS
- Formatting Code
There are a few additional sections, but for the purpose of this review I’d like to focus on the overall structure and message of the book and try to explain why I think it’s so valuable.
Jonathan is trying to explain his fundamental approach to CSS as a whole. We’re far beyond simple tips and tricks and instead focusing on the big picture approach, how you’d handle the overall architecture of the way you style an entire site from start to finish.
Jonathan begins by explaining that he’s broken down CSS into four parts:
This is the foundation of SMACSS and the segmentation is discussed throughout the book. Jonathan focuses on the fact that writing effective CSS means cutting down the amount of CSS while striking a balance with specificity. Thinking about CSS in these four parts is fundamental to SMACSS. Jonathan outlines specific definitions for each of the four categories of CSS.
- The defaults. They are almost exclusively single element selectors but it could include attribute selectors, pseudo-class selectors, child selectors or sibling selectors.
- Divide the page into sections. Layouts hold one or more modules together.
- The reusable, modular parts of our design. They are the callouts, the sidebar sections, the product lists and so on.
- 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?
Understanding this segmentation is essential to the SMACSS concept. The naming rules for each of the four categories are explained in the chapter as well. From there, a much more elaborate explanation of each is offered, putting more context to the reasoning behind the classification. Additionally, working examples are provided along the way, offering some context as to why Jonathan has come to these conclusions surrounding his method of writing CSS.
Perhaps the most complex category in the group is that of state. I’d be willing to bet that while most people do (correctly) use CSS classes to control the state of various elements on page, most do it with the sledgehammer called specificity. Jonathan takes the time to thoroughly explain a targeted approach to styling state that will help avoid both frustration and confusion down the line.
One of my favorite sections of the book is Depth of Applicability which outlines at length the necessity of finding a balance between dependency on HTML structure and specificity of your CSS. The fact of the matter is, you don’t want the way you’ve written your CSS to grossly over-effect the way you need to maintain your HTML.
Jonathan also touches on what appears to be a growing topic, Selector Performance. While changes are often negligible, performance will continue to grow in importance as the CSS layer is doing more complex things like border radii, box shadow, and other more intense operations.
I could outline why I like each and every chapter of SMACSS but instead I’d like to encourage you to give it a read. By far one of my favorite additions is the recently added screencast outlining how Jonathan would apply SMACSS to someone else’s project after he had become frustrated with implementing SMACSS on his own. Additional members-only features look to be added in the future, so that’s something to consider after you’ve perused the contents of the book.
SMACSS started out (and continues to be) a free ebook. A pricing model was introduced that gets you access to platform versions (PDF, Kindle) and there’s also a Lifetime Membership available with additional benefits, including a discount on the workshop Jonathan has built from this endeavor.
SMACSS can be read in a single sitting, and I think it should be. In fact, reading it a couple times over a couple of months would be a great idea in my opinion. It’s important to take the advice into account while working, and the only way to do that is to pick a piece out that you think will integrate well and try it.
Breaking habits is hard, especially when it comes to work. People get settled in their ways and if it works, it works. Don’t fix what’s broken. It’s important, though, to qualify your methods from time to time in an effort to make sure you’re still doing not only your clients justice, but yourself by producing the best work possible. What better way to do that than to compare your workflow to a highly respected professional?
I can’t say enough how refreshing it was to read SMACSS as Jonathan has put into words something I’ve struggled to vocalize for some time now, and done a better job than I could have hoped to do. His recent experience at Yahoo! really puts the book into perspective and shows the application to working among teams on very large scale projects, something you don’t often get a look into as an observer.
While Jonathan isn’t touting SMACSS as the end-all-be-all for CSS, he rightly explains that CSS deserves a targeted process, a style guide, some sort of structure. He doesn’t think that everyone should use his, but hopes a glimpse at how he works will help you refine (or define) your own.
Thanks for the review! It pushed me over the edge and I went ahead and purchased the book, excited to see what it holds! CSS is the thing I am reasonably skilled at from a coding perspective, but always feel like the organization starts out well – then disintegrates over time.
Thanks again for the review!
Good review man. I completely agree. I’m not really interested in the latest CSS3 trick because I can figure that out by reading documentation. I am, however, really interested in organization, structure, best practices and how people approach coding / programming from a conceptual standpoint. And this book was exactly that.
“[I] always feel like [CSS] organization starts out well – then disintegrates over time.”
Bingo. I think that’s the central issue for most of us well-intentioned folks writing CSS, and it’s almost shocking how useful Mr. Snook’s writing can be in focusing attention on the right questions for addressing this core concern. I’m glad you’re going to check it out!
[…] about separating out stylesheets and for me it came down to the rules for separation. After reading SMACSS it clicked. Instead of splitting up selector properties per file, group selectors based on their […]