I'm David Little, a user experience researcher and designer

Getting to know-o-css

Posted: October 2, 2011

Getting object-oriented

Over the last few months I’ve been increasingly impressed by the Object Oriented CSS (OOCSS) approach to coding CSS, adopting the methodology as far as I understood it for one freelance project I worked for and in the redesign of my own website.

When I took on the project of updating the front-end development framework in my current workplace it was no surprise then that I decided to base it both on the OOCSS philosophy and parts of the CSS framework (there is a subtle difference). I thought it was about time to record my thoughts on using it so far and give my take on some of the issues that have arisen.

Why OOCSS?

OOCSS is a different methodology for writing CSS which is far saner than most of the other approaches I’ve used in the past. In a nutshell, OOCSS:

• encourages re-use of CSS styles across a site
• uses the concept of CSS “objects”, that is predictable code based around the content that object will contain
• instead of endlessly creating new styles, uses the concept of extending styles
• discourages the use of location-dependent styles where possible

If that sounds a little abstract, it really means adopting a set of coding practices (and mindset). Here’s just a few examples:

Never style on IDs, only on classes

Styles on IDs cannot be reused as you can only have one ID per page. Classes on the other hand can be reused any number of times. IDs also take higher precedence than classes, so using them can soon lead to specificity wars in your stylesheet (the nuclear option in which is the use of the !important declaration,  an indication you’ve just entered a whole new world of pain)

Use classes where you can

Another way to start a specificity war is to over-use location-dependent styles, i.e. by cascading styles down via containers. Instead, create a specific class (NB this might not always be possible or practical — more on that later).

Extend styles

Let’s say you have a style for a box and want to create a slightly different style for another box — instead of creating a brand new style, simply extend an existing one. For instance, have a base class for one kind of object and extend it by providing extra style declarations in an extension class, e.g.

<div class="stupidBox box1"> I'm a stupid box </div>
...
.stupidBox { width:200px; height:200px: border:1px solid;}
.stupidBox.box1 { background-color:#ccc; border-color:#333;}

Hang on,

You can’t throw out location-dependent styles just yet

Ever worked with a CMS? Chances are the answer to that question is “yes”. In which case you’ll be dealing with CMS-generated content appearing in at least one predefined area of your page. Which means you’ll need to be using the cascade to ensure the content is styled properly — yes, location-dependent styles.

Ok, location-dependent styles aren’t wrong per se, the trick is to handle them so they won’t cause specificity issues in the rest of your stylesheet. To do this cascade them from elements nearby rather than further away (think containing classes, certainly not IDs applied way up in the page).

I’ve created some reusable styles — but what happens if my site design changes?

Once you get into OOCSS you may get swept away with excitement at the levels of abstraction you can build in (if you don’t get out much that is). Need a load of different inline lists? Create an inline style instead of applying inline styles to each; want to apply CSS3 box shadows to an element — just create a box shadow style.

Yes, there is the danger you can end up with a bunch of presentational styles that will suddenly won’t fit your new design (e.g. two of those inline lists are now block level lists, the box shadows are just so out). This is a particular danger for larger sites which might undergo a number of design interations without substantially changing the HTML output.

Be pragmatic

In my experience redesigns usually (no, scratch that, always) go beyond CSS tweaks and style refreshes to something more fundamental which will involve a larger code overhaul.

That’s not to say you should get into the habit of creating purely presentational class names but it is important to think about the level of abstraction you want to go to.

For instance I always create an inline list style as it’s such a common design need. However, I’d think twice about creating styles such as .redBox, .dropShadow or abstracting out common typography styles (e.g by creating a .fontFamily1, .fontFamily2 class etc.).

Grids

Similarly, and a problem not confined to OOCSS is the use of grid systems. I use the OOCSS implementation of grids as the basis for creating my own grid layouts. However, “out of the box” these are designed for desktop browsers and are not responsive so will not always be the best fit for mobiles or maybe even tablets.

Having said that there is no reason that they cannot be made responsive by gradually loading in resources depending on screen resolution. Going mobile is often a case of looking beyond the technology anyhow and concentrating on what you want to serve up — in some cases this may be a subsection of content styled (and structured) very differently to the desktop experience.

My implementation of OOCSS

Thinking in terms of OOCSS has led me towards code modularisation. In a multi-skilled environment it’s not just the designers and front-end developers who are creating HTML, but also often the back-end developers.

By thinking in terms of objects I’ve found it more straightforward to break down code into pluggable chunks which developers can take from a growing snippet library.

Predictability of code structure makes it easier to implement common design patterns and for others to pick up and run with others’ code. Consider a block of code for implementing tabs (and with apologies to the OOCSS authors, I’ve chosen to use “modules” in a slightly different way to theirs).

The structure of the code reflects the needs of the particular plugin I’m using, jQuery Tools. However, the class names for the elements of this particular module are generic enough to be able to be applied to different implementations (although for the sake of saving development time you may want to agree on the use of a common set of tools, whatever they may be).

A tabs module

<div class="mod tabs">
 <ul class="tabControls inline">
  <li class="tabControlHeader"><a href="#tab1">Tab one</a></li>
  <li class="tabControlHeader"><a href="#tab2">Tab two</a></li>
 </ul>
 <section class="tabContent" id="tab1">Tab 1 content</section>
 <section class="tabContent" id="tab2">Tab 2 content</section>
</div>

CSS

Unless your sites all look the same it’s probably harder to have a CSS library tied into this beyond basic resets and common presentational classes (or maybe recipes for vertical and horizontal grids), but at least CSS authors will have predictable code objects to work with.

No silver bullet

I don’t believe any framework is a silver bullet and every site build is inevitably going to be a series of compromises but I think this is a positive step forward away from the nightmare of CSS bloat and specificity headaches.

‹‹ More writing