Before I get started, I just want to make it clear that this review of OOCSS is simply my take on the methodology and my method of comprehending it. There seems to be a lot of different views on the topic, and I’m sure I don’t have the perfect answer, but hopefully this article will help others struggling to comprehend OOCSS in one way or another.

My take

Object oriented CSS (OOCSS) is a methodology of writing reusable CSS that is fast, scalable and maintainable. It’s the first of the popular CSS “systems” (SMACSS & BEM are two other popular systems) that aim at making CSS more modular and scaleable. First introduced by Nicole Sullivan at Web Directions North in 2009, the object oriented concept comes from, as you probably guessed, more traditional engineering practices that are used in programming languages like PHP, Ruby or JavaScript. But in layman’s terms, objects in front-end development are simply HTML elements. The CSS is where we make those objects, or elements, modular and location independent to be able to place them anywhere on a page and behave predictably. And it’s done by adhering to Sullivan’s two main principles: separating structure from skin and container from content.

Separating structure from skin means to abstract the structure and positioning styles of an object from the presentational styles, or skin.

Separating container from content means to break components’ dependency of their containers. Any object should be able to be placed in another container and still look and behave the same.

We’ll pick these two principles back up in a bit, but first let’s talk about why and where the object oriented methodology is beneficial.

Why write object oriented CSS?

I mentioned above that object oriented CSS its fast, scalable and maintainable. But how?

It’s fast because, if done right, there is almost zero repetition. object oriented CSS is DRY as can be. As a site grows in complexity, CSS usually grows too. And grows. And grows. Until the CSS files downloaded by the browser are a heck of a lot larger than they should be and more specific than they should be and could be if you were writing object oriented CSS.

It’s maintainable and scalable because there is no repetition in our CSS and classes can be re-applied and mixed on different objects at free will, without worrying a whole lot about the context they’re in. So instead of adding on to the CSS as a project gets passed from developer to developer, developers can just reuse because everything has been abstracted out.

Also of mention in the “why object oriented” statement is the fact that it introduces standards that make our sites less brittle to newcomers to the project. We can write great high performing code, but if someone else can’t touch it, it’s not so great in the end.

And finally, where is object oriented CSS beneficial, and should it be used on every project, big or small? Well, the origination of the methodology came mainly out of the need for CSS to scale. So the biggest performance and organizational gains are going to be seen on larger projects with multiple developers and lots of files and pages. However, writing object oriented CSS is still a great habit to get into on any project. It makes code much easier to pick up at a later date without not knowing where to start and just adding on.

Separate structure from skin

Back to our two principles we need to adhere to. The first is separating structure from skin or, in other words, positioning (position, float, margin, etc.) from styling (background, color, border, etc.). In practice, this essentially means to not mix structure/positioning properties with skin/styling properties on the same class. This way our “skinning” properties can be reused on a variety of elements, preventing property duplication in our CSS.

Separate container from content

The second of Sullivan’s principles, separating container from content, is done to allow the re-use of elements and classes no matter where you are in the DOM. A styled element should never be dependent on where it’s at in a page. For instance, a latest news module found in a sidebar should not be defined by its current place in the sidebar. It should be movable to a main content area, another module, the footer, so on and so forth.

Non-OO example

Let’s look at the example of a latest news sidebar module with some markup and CSS, using a traditional method of element selectors and inheritance.

Object oriented example

And now we’ll take that example and use the principles of object oriented CSS to make it much more location independent and DRY.

Now yes, our HTML did get a lot more complicated with all the extra classes. But in the long run, we’ll now be able to create many elements without even having to touch the CSS. Want a section heading somewhere on your page? Just give any element a class of section-heading! Need another unordered list somewhere with no bullets? Give it a class of item-list.

The “classitis” tradeoff

If there’s one downfall to object oriented CSS, it’s the bloating of HTML with classes (commonly referred to as “classitis”). Separating structure from skin and container from content results in more classes on elements than we’re probably used to. I’ve questioned myself whether or not I’d rather have DRY CSS or DRY HTML, but have come to the conclusion that DRY CSS using the object oriented methodology is preferable due to its maintainability. Granted, it can be slightly annoying to modify an element’s classes, but as long as you’re not completely “describing in the browser“, it’s not too bad. There are plenty of opinions about using Sass or LESS extends to extend classes in the CSS and just have one descriptor class on the HTML element, but while it may make the CSS easier to maintain before it’s compiled, the CSS is no longer DRY when the browser reads it.

appendTo offers Web Development Training Courses for Teams.