I’ve been holding in a deep, dark secret that could easily get me kicked out of Blue Bottle or Philz during the late morning rush. I don’t know how do write quality CSS. That’s right. I built my first website in 1995 and have been making things on the web professionally since 1997, but like many engineers I know, I’ve been cargo culting CSS for about as long as that’s been possible.

Where do I find “best practices” for developing coherent & cohesive CSS???

I recently took this secret to my therapist twitter and saw that I wasn’t alone. 15 years ago we were building HTML by hand with <font size="2"> tags. Now we have Rails. Let that sink in a bit. That’s an insane amount of progress. BUT… Look at the CSS for virtually every big web app and the CSS is a disaster. There’s a mix of naming conventions, no organization, loads of repetition and probably hundreds if not thousands of lines of styles that are not even used anymore. So… how do we do it right? You can find a CSS snippet for a 3D spinning logo on fire on a thousand websites right now, but where are folks taking about building coherent, cohesive and maintainable CSS? How can we apply the practices of regular programming to CSS?

Enter: Object-Oriented CSS

Nicole Sullivan, aka stubbornella, wrote about her oocss framework in 2009 and has been whacking sense into folks ever since (and probably long before). Be sure to read the original OOCSS blog post that started it all and check out Nicole’s presentations, all of which are pure gold. (And many, many thanks to Brent Miller for turning me on to this!)

Of the 10 Best Practices highlighted in the original presentation, these three had the biggest effect on me:

  • Separate structure and skin
  • Separate container and content
  • Extend objects by applying multiple classes to an element
  • (*Bonus #4!) Use classes for style. Save ids for JavaScript.

Object-Oriented Design Heuristics

Once we purposefully design CSS in an object-oriented fashion, suddenly a whole new world opens up. We’re no longer jamming in long CSS rules with repetitive styles. We’re creating unique, small classes that can be composed to style our elements. Hey, that sounds like real programming! Let’s do this!

Object-Oriented Design Heuristics is one of my favorite programming books. Inside the cover the author lists about a hundred heuristics for object-oriented programming. If you’re looking for the 1996 winner of the “best index” award, this is it. Here are a few of the heuristics from the book, applied to OOCSS.

A class should capture one and only one key abstraction

This is a more specific goal than the best practices listed above. To me, this means creating different classes to handle style behavior that isn’t always going to be used together. The anti-pattern version of this though is to have loads of tiny classes that do very little and elements that need a dozen classes to work right. Herein lies the art of good OOCSS.

Do not create god classes in your system

Similar to the earlier statement, we shouldn’t see classes with a large number of styles specified. I wonder what a good rule of thumb is? How many lines does a CSS class need to be before it’s too big?

Model the real world whenever possible

Semantic names! Now that we’re not cluttering our classes with dozens of styles, we can name them well. Think first of the “user” of your CSS. When someone is reading the markup, they see a list of class names styling an element. How easily can they visualize where and what an element will render like by reading those names?

Minimize the number of classes with which another class collaborates

I’d argue that we should work hard to break this rule. We are composing classes (collaborating) as a rule. We should aim to limit the number of classes necessary to achieve a desired style, however.

A class must know what it contains, but it should never know who contains it

This is huge. This specifically relates to separating structure and skin. Classes should be portable.

Inheritance should be used only to model a specialization hierarchy

Related: “Choose composition over inheritance”. Think of it this way: The DOM represents inheritance, while custom classes are used in composition.

Factor the commonality of behavior as high as possible in the inheritance hierarchy

Great rule for CSS. Leverage that “cascading” effect of CSS. Place common styles as high up in the inheritance hierarchy (DOM), and override when necessary.

Classes over IDs

I’m calling out bonus point #4 from above for a second time because it’s really important. Nicole says we shouldn’t use IDs to style elements because an ID is supposed to refer to a single instance, and our goal of OOCSS is reusability and composition. There is an even more plain reason to use classes instead of IDs, however. An element may have zero or one IDs assigned to it, but an element can have many classes. Compose styles out of several classes and keep your IDs to actually identify a single element, most notably when you need to grab it with JavaScript.

Submit your own rules for OOCSS!

I’d love to hear your object-oriented rules for creating good, maintainable CSS. Add them in the comments, email me or copy me on twitter @briandoll and I’ll add them to this post.

Note: I’m aware of Saas and Compass, but for the purposes of clarity around OOCSS, this post is aimed at bare CSS. I know lots of folks love CSS generator frameworks, I guess I’m just not there yet personally.

This article was translated to Serbo-Croatian by Anja Skrba from Webhostinggeeks.com.

Discussion, links, and tweets

Follow me on Twitter for more musings from the ether.

© 2007-2015 Brian Doll