Thoughts on Object Oriented CSS

If content is King then performance is Queen. In today’s world of insanely fast internet connections, the effects of spaghetti code on load times are becoming increasingly more noticeable. There are developers whose entire career is built on refactoring code for better performance. You hear about this type of work often in the realm of Javascript, PHP or Ruby but it’s often overlooked when dealing with CSS. Bloated CSS is less expensive than a bloated JavaScript function at load time. If you’re trying to write code that’s easier to maintain and helps you gain milliseconds you might want to have a look at Object Oriented CSS.

As with any object based coding method the goal of OOCSS is to encourage code reuse and stylesheets that load faster. You can check out the OOCSS github wiki here. It outlines the 2 main principles:

1.)Seperating the Structural Elements from the Skin

Most visible elements within a styled HTML document have varying visual features that are re-used in different contexts. Think colors, fonts, etc… Likewise the block level elements or structural pieces are also re-used. When these different elements are abstracted into classes they become reusable with less code. Let’s compare some code so you can see what this might look like:

The three elements you see here have different styles all applied using the non-reusable id selector. If we reassess this code a bit we find that they have properties in common. We can abstract the common styles to get to something like this:

Now these examples are using classes and we’re cooking with fire. The common styles are thrown into one “visual,” class that can be applied over and over again without rewriting the same code. As you know classes can be called within a block level element in order of inheritance like: <div class=”thingy visual”></div>

2.) Seperation of Content from the Container Elements

This seems like a pretty straight forward concept but let’s take a moment to illustrate why this might be important.

Now here any 3rd level headers that are children of the #thingy element will inherit these styles. But what if I want to call identical styles with a couple of changes in the footer? Then we would need something like this:

Now we’re really duplicating code that could be written once… sheesh — it’s like a unicorn exploded repeatedly!! With OOCS we’re encouraged to analyze this a bit deeper and if we enact these best practices guess what… we get better load times! and code that’s easier to manage.

The styles that are declared using the descendant selector in those above examples are not reusable, because they are dependent on a particular container (in this case either the sidebar or the footer).

When we use OOCS’s class based model we ensure that our styles are not dependant on any single containing element and we are free to use them anywhere within our documents regardless of structure.

This new way of approaching CSS begs the question — well why not just abandon using IDs for block level elements? and.. Can’t that cause new problems for DOM applications that rely on hash events ?? These are good questions to which I reply: You can use IDs in tandem with classes! In some cases it’s a good idea to have both — just don’t build your styles using IDs as selectors.

CONCLUSION:

Utilizing OOCS is easy and the benefit is great. Remember to avoid using descendant selectors. Don’t use IDs as hooks for styling. Avoid attaching classes to elements like div.thingy or h1.title when at all possible. Use GRIDS .