The 2 Principles Of Object Oriented CSS

Posted: 12 Mar 2012 05:30 AM PDT

Do our current css practices scale? Are our stylesheets easy to maintain? Can non-css coders quickly and easily to build new web pages with our styles? Object oriented css (OOCSS) is an approach to writing html and css that allows us to answer yes to each of these questions.

Over several recent posts I’ve been exploring topics around our approach to writing css. Last week I talked about classes being one form of abstraction in css. OOCSS pushes classes to the forefront.

Please know that I haven’t had a chance yet to use oocss concepts in practice to any great degree and so this post is mainly based on research about the subject. If you haven’t previously seen it, I recommend watching Nicole Sullivan’s presentation on Object Oriented CSS. I’ve included her slides from the presentation further down in this post.

What is Object Oriented CSS?

CSS is not an object oriented language and the programmer in you might be cringing at the name. Still it’s not hard to understand why Nicole chose the object oriented moniker.

A css object is any repeating visual pattern, which can be abstracted into a snippet of html, css, and sometimes javascript. These visual patterns become objects or modules through css classes that can be reused throughout a project or projects.

The goal of Object Oriented CSS is to encourage code reuse for faster and more efficient stylesheets that are easier to maintain. OOCSS is a also framework developed by Nicole Sullivan based on 2 main principles

Separate structure and skin
Separate container and content

Let’s look at each of these principles in a little more detail.

Separate Structure and Skin

Most every design is going to have repeatable visual elements. It may be consistent background colors or border styles that elements share or it may be something else, but the patterns will be present.

You might for example have several buttons throughout a design that share size and shape as well as a thin border and small border-radius to round the corners. You might also style boxes around content that have a different width and height from the buttons, but share the same border and background properties and radius.

 #button {   width: 100px;   height: 25px;   background: #ccc;   border: 1px solid #333;   border-radius: 5px; } #box {   width: 200px;   height: 400px;   background: #ccc;   border: 1px solid #333;   border-radius: 5px; }

There’s a lot of duplication in the above code. At the moment the only thing differentiating the button from the box is their height and width. If later you were to add another element with similar background and border you’d likely grab the code and copy and paste to a new selector leading to yet more duplication.

When you’re dealing with only a few selectors this might not seem like a big deal, but it shouldn’t be too hard to see how this eventually grows into a maintenance issue and I’m sure you’ve worked on some sites where it has been an issue.

Instead why not define the repeating visual patterns common to all as separate modules or skins that can be reused?

 .button {   width: 100px;   height: 25px; } .box {   width: 200px;   height: 400px; } .skin {   background: #ccc;   border: 1px solid #333;   border-radius: 5px; }

These classes become objects we can add to our html and have our elements look consistent. Classes can be mixed and matched to create greater variety and flexibility in the display of elements.

 <a class="button skin" href="">button text</a> <div class="box skin">box content</div>

This approach makes it easier to integrate new html elements without having to style them. You learn what objects (classes) are available to you and you add them to your elements.

Elements can use semantic html for their structure and different classes can then be added to describe the presentation of that structure.

Separate Container and Content

Rarely should we use location dependent styles, because those styles become locked into specific selectors. A visual object should look the same no matter where you place it. For example:

 #sidebar ul {   list-style: none;   font-size: 0.875em;   color: blue;   margin: 0;   padding: 10px }

The above styles are locked into unordered lists in #sidebar. They can’t be used on a similar list in #footer without some duplication of code. You could do something like the following to lessen the duplication.

 #sidebar ul, #footer ul {   list-style: none;   font-size: 0.875em;   color: blue;   margin: 0;   padding: 10px } #footer ul {   font-size: 0.75em;   color: red }

The above reuses the original styles, but requires some be overwritten. I’m sure the above looks familiar. I’ve written css like this and I’m sure you have to. The problem is the more css we add like above, the more we start needing to overwrite and then overwrite again, creating specificity issues.

On most projects you probably have a default list styling, another set of styles for the list that becomes your global navigation, yet another for secondary navigational lists, and perhaps another for random lists that appear in a sidebar or footer.

Your css starts out clean enough with what you think will be default styles, but each new type of list overrides the default and the one that came before it. Better is to not tie your css to location in the first place.

On a small project this duplication might not seem like a lot, at least until 6 months have passed and you need to make a change. It will certainly add up as your project gets larger.

What OOCSS asks us to do is spend more time upfront thinking about what will be common across different elements and then abstract those commonalities out into reusable modules. We don’t however want to attach our modularized classes to specific elements. Instead of div.box we want .box. The latter allows us to add the box styles to any container, while the former ties them to divs alone.

Getting Started

The hardest part of adopting OOCSS will probably be the change in thought process. We’ve been following the same habits and best practices for such a long time they’ve become ingrained in our workflow.

It might help to slowly change some of our css practices.

Abstract common styles into classes (objects) for reuse
Think classes for styling hooks
Think ids for behavioral hooks
Stay away from descendent selectors
Avoid location based selectors (.box instead of div.box)

If you’re looking to use OOCSS without having to dive in all at once, following the above guidelines where you can and making them habit might be your best approach.

You may also want to take a look at the following resources

Object Oriented CSS — more presentations from Nicole Sullivan

Closing Thoughts

As I said at the start, this post comes more from research and less from practical experience with OOCSS. It all seems very logical to me and good way to approach writing and applying css to your html. However theory and practice don’t always mesh.

Some of the benefits of Object Oriented CSS are as follows.

Greater reuse of styles — modules of css can be added anywhere
Less duplication of code — Repeatable css patterns are in a single location
Flexibility and variety —by combining classes
Faster sites — less duplication should result in smaller file sizes
Ease of maintenance — Code is located in one block instead of many
Standards based — Easier to improve one block of code instead of many

Again these will have greater impact the larger the project, but most should still impact sites of any size.

While much of this talk focuses on single sites, it stands to reason some of the objects you create could be reused across projects as you build a library of visual styles and develop your own visual language. Some details of .button and .box might change across projects, but the concept of .button and .box are likely the same.

I wonder about the coupling that comes from adding more classes to html, though current practices also couple css and html rather tightly. The more I think about it, the less of a practical issue I think this is. For example a site like this one sitting on WordPress (or any CMS) would have classes attached to content that is stored in the database and typically unchanged during a redesign.

However, that happens with any redesign and as long as classes have been named well they should be available for reuse or at least not get in the way. Worst case is leaving some now unused classes on html elements.

One last criticism of OOCSS is that is seems to eschew the use of ids entirely. That’s not the case. The idea is to avoid ids for styling, but to still use them for javascript hooks. OOCSS isn’t saying classes are better than ids, but rather that each is more appropriate in a different place. Classes for presentation styles and ids for behavioral hooks.

Again though I haven’t used OOCSS in practice to any great degree, it seems like a very logical approach to writing html and css and I’m looking forward to incorporating the basic principles into my work.

Are you using OOCSS? If so what do you think? Does the practice live up to the theory?