The 2 Principles Of Object Oriented CSS

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.

CSS written across an Apple Cinema display

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.

{code type=css}
#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?

{code type=css}
.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.

{code type=html}
<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.

Table of contents from a book

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:

{code type=css}
#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.

{code type=css}
#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 we want .box. The latter allows us to add the box styles to any container, while the former ties them to divs alone.

Start spelled out in Scrabble tiles

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

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?

« »

Download a free sample from my book, Design Fundamentals.


  1. I think that Object Oriented CSS is very unfortunate chosen name, it seams like is something very complex and abstract system.

    What it actually is: Making less specific CSS classes.

    This can work on both small and big web sites. Only downside is you need more planning ahead and you need to think about your site and CSS architecture. Naturally you can use ID but your main architectural construct is with Classes.

    Why this technique can newer go on large-scale? Because people always choose the path of less resistance or they prefer to write more code as they go but only few will write and optimize the CSS code before the HTML coding.

    • I agree about the name. I can understand why Nicole chose it, but I think it leads people to think OOCSS is something it isn’t.

      Interesting point about people choosing the path of least resistance. I hadn’t really considered that. It probably will be what keeps people away from something like OOCSS. Hopefully enough of us will do the upfront planning regardless of whether or not we use OOCSS, but I think you’re right that most people will choose the easier route and write css as they go.

    • “Object Oriented” is a loaded term to any programmer and I don’t think it really applies here. He really seems to be talking about using a form of inheritance to reduce repeated code. I think following DRY as general principal is good but maybe this is not the best way to approach it. For starters, CSS already has inheritance (the C in CSS) so basically we are layering a second form of inheritance on top of what is already intrinsic to CSS. I suspect that attacking DRY using another method such as a CSS preprocessor might be less confusing for people and provide similar benefits.

      • I agree this isn’t really object oriented, but I understand why the name was chosen. There’s a similarity in the concept of thinking about visual patterns as objects.

        The problem with the default inheritance of the cascade is it leads to specificity issues that are hard to maintain over time and as sites grow larger.

  2. Object oriented CSS is a nonsense. CSS, no matter how complex it could be, is only a “property” of the real object, the html. So, this only helps to add another layer of complexity to an already complex web design scenario. If you keep your CSS code clean and ordered, there is no need to create such objects to deal with later.

    • I wouldn’t call it nonsense. The point of oocss is to help keep your css clean and ordered. Using descendent selectors isn’t going to be a big deal on a small site. It’s easy enough to keep things organized and duplication can be kept minimal.

      On larger sites the duplication adds up and maintenance can be a nightmare. Even small sites grow beyond the point where they’re easy to maintain and keep organized.

      I’m not suggesting you have to use oocss or it’s the best approach to organizing css. Just that it’s one possible approach and I think the basic principles behind it are good ones.

  3. OOCSS is a direction I was heading anyhow when I saw a presentation by Nicole Sullivan in 2010.

    It confirmed with I see wrong with the way most people write CSS. A mess of disorganized repeated properties and selectors that just get stronger and more repetitive.

    Styling with classes, without ids and minimal use of elements in the selectors, allows you to write much more organized readable CSS. Additionally, it is much faster as you use Firebug less.

    I mostly work with Drupal and OOCSS works great with it. You may want to kill off module stylesheets (see the Tao base theme). There are lots of common and unique conventions in Drupal classes which makes it a natural way to go.

    OOCSS is truly object-oriented if you writing Sass/Compass. Extending base classes makes for better organization regardless of how you write CSS.

    If you write CSS for a living, OOCSS just makes sense.

    • Interesting Tal. I agree with you about the mess and organization. I think a lot of web designers start a css file with good intention, but the more you work on it, the more disorganized things get. You add something here and change something there and before you know it your good intentions are lost.

      Good to know about its combination with Sass/Compass. I’m working my way toward exploring both in a future post. A couple more things to get to first. I’ve been thinking that an approach where css is written more with classes in combination with a preprocessor is ultimately what I’ve been looking for to help me maintain my css the way I want.

  4. You can make your OOCSS even more readable with Sass.
    For example you can @extend a base class or nest selectors.

    There is a Firebug extension call FireSass which makes line number match up with you .scss files.

    I am just learning myself as I go in the redesign of my portfolio site.

    Thanks for giving OOCSS some love!

    • Thanks Tai. That’s what I was thinking. This all started with a desire on part to organize css in a way other than the usual top down approach most of us take. I’ll be looking into SMACSS next and then want to look at css preprocessors, mainly Sass.

      I think a combination of preprocessors and organizing around classes is ultimately what I want.

      Thanks for the mention of FireSass. Sadly I don’t Firefox for development much any more. FF gets too slow so I mainly use one of the Webkit browsers for development. I’ll have to see if they offer an extension for Sass. If not I may have to start using FF more.

      I’m getting close to finishing a redesign here, though unfortunately I started looking at OOCSS and Sass after I’d done too much work. I probably won’t have any of it included at first, but I plan to refactor everything sometime down the road.

  5. You say that these are sort of “thinking out loud” from research. To me they don’t seem like they would be the most “straight line” approach, and therefore wouldn’t be the most intuitive. However, if we don’t start to do something that makes sense one of these days we’ll be buried in code and complexity.

    Just another thought, if you carry this on to an absurd level – more and more of our design coding could be “shifted” back into the HTML markup (i.e. more and more ‘classes’ in our code)

    • True if carried too far we’re moving everything back to html. The decrease in css files size through OOCSS does lead to an increase in file size of html, though according to Nicole the overall file size of the two is reduced.

      I think there’s a middle ground here. Monday I’m posting about SMACSS, which aims to be that middle ground. I think what’s most important about both is the principles behind each. It’s likely we’ll each develop our own practices based on these underlying principles.

  6. I have been using a “panel based” architecture for a while where everything on the page is effectively a panel which I then extend with different classes.

    Typically it would look something along the lines of class=”panel bdr bg cnr shadow etc etc” I’ve found this to be robust in the way that I do things as every site I’ve ever worked on is effectively made up of panels that do different stuff.

    OOCSS is great fun to use, the only thing I find hard and continue to try and build upon is building up patterns that can be used across various sites.

    OOCSS combined with pre-processors are super powerful however abstraction is still really hard to achieve and there are always exceptions. Making good use of these two techniques can really help you deal with exceptions more effectively.

    Great write up!

    • Thanks Alan.

      Interesting. The term “panel design” is new to me. Is there information online about it or is a making of your own creation?

      In principle I can see how the ideas of OOCSS can be extended across sites. I have some ideas for how, but will need to put them in practice before knowing if they could work. I’d imagine it would take a lot of discipline and abstraction to make work.

      I think the combination of OOCSS (or SMACSS) and pre-processors are going to be what I want. I’m still working my way through understanding each and it’ll be awhile before I can put some of my thoughts into practice. I have a hunch I’m going to really like working with Sass.

  7. While I appreciate what OOCSS (or whatever we’re calling it) is trying to achieve, there’s something about it which doesn’t feel right to me, but maybe that’s because I’m already converted to SASS.

    I admit they won’t solve the specificity thing, but when it comes to minimising duplication, CSS preprocessors are _perfect_. This is how your #sidebar/#footer example might look in SASS:

    @mixin listBase($fontsize,$col){
    list-style: none;
    margin: 0;
    padding: 10px;
    font-size: $fontsize;
    color: $col;

    #sidebar ul{
    @include listBase(0.875em,blue);

    #footer ul{
    @include listBase(0.75em,red);

    I think that’s pretty clean and maintainable. How would the OOCSS look?

    • I haven’t explored Sass in any depth yet, but I think it could be used in combination with OOCSS or SMACSS. The latter two are mainly pushing us toward using classes instead of descendent selectors like #sidebar ul and #footer ul. Both would more likely suggest using a class.

      .class1 {
      @include listBase(0.875em, blue)

      .class2 {
      @include listBase(0.75em, red)

      The classes would have better names than class1 and class2 of course.

  8. I got all excited when I saw the term ‘object-oriented_CSS”, especially as someone from a ‘classical'(are we old enough to use such a term yet?) programming background.

    But really this is all about neat compartmentalising and compressing of CSS – finding the generalisations.

    For me, planning ahead too much can destroy the creative process – I like to go with the flow and create messy CSS when the passion is upon me…. then tidy it all up later when in more reflective mode.

    Thanks for the article.

    • Sorry about that Stanley, though I can’t take responsibility for the name, since it wasn’t of my choosing.

      There is something of objects in the sense of coding specific visual objects into classes as opposed to mixing part of those visual objects directly into element and ID selectors. Not exactly the objects of programming though.

      I don’t know that this has to hurt creativity. If you’re designing in a graphics editor it shouldn’t matter, but even if like me you do some design work in the browser itself I don’t think it has to hurt.

      You could do what you do now and refactor into classes later like you say. Plus I think it’s more getting used to a different process and once you’re used to it, it’s just another tool. Maybe it would lead your creativity in a different direction, but I think you’d be able to be just as creative.

  9. It is very interesting, thanks. I use to do something similar to this to reduce my overall stylesheet, the .box, .button and .skin idea is cool. Will try it in my upcoming projects.

  10. Hey, I do all of this already. I thought most designers did, I thought it was common practice.

    I tend to split the style sheets out to make it even clearer

    – typography
    – structure
    – paint
    – accents
    – reset

    • I think it’s been a few years since these Nicole first started talking about all this stuff so I’m sure there are designers out there using OOCSS already. I’d guess most still don’t and there are some who don’t think it’s a good idea.

      What do you think of OOCSS?

  11. I just wandered on here. Object oriented makes sense to me. You create and define the object, give it a name (class or id), and call it at will.

    Seems to me that the CSS becomes a warehouse of styles, rather than defining the HTML. It may be apples and oranges, but I think following an oocss mentality will help keep designers closer to the true intent of CSS.

  12. When speaking of Object Oriented CSS (OOCSS), what elements of CSS are considered “structure” and which are considered “skin”? I am probably a bit of a gray area thinker and while an element like width easily falls in to the structure category and color or background fit into the skin category, what about an element like border which affects both structure and skin?
    I see that I am not the only one having issue with this because even the best articles I have read on OOCSS are inconsistent with one another.
    If this is going to be a standard of practice we need to agree on which items are skin and which are structure. If everyone is doing their own interpretation of OOCSS it loses its effectiveness.
    A final thought for me is that maybe I am not understanding the skin vs. structure well enough. If this is the case I welcome the correction.

    • I know what you mean about borders. I’ve had similar questions myself. I tend to think borders presentation now. Any structural impact they have can easily be removed.

      I think you have to think about it more in terms of the visual element being the object and deciding what’s structure and presentation for that visual element.

  13. By and large “OOCSS” is nonsense! There is no such thing as an “object” in CSS land. Its just another layer of abstraction on something thats quite simple; use common sense when structuring your CSS, componentise your CSS but don’t tie it to each other. That last bit is exactly what you’re doing with OOCSS. It will cause you major problems when things change if you have lots of things depending on the structure. Its too high risk on big projects when you got clients that can change their minds in a second.

    Its one of those paper world ideas (like SCRUM HAHAHA) that’s great in 2D but in the 3D world (real world) it will cause you issues eventually.

    I’ve started using ITCSS by Harry Roberts (and namespacing my css) which is just a way to structure your CSS projects – It’s great check it out. He has an Objects layer and a Component layer . What he says about the object layer is “it maybe used in any number of unrelated contexts to the one you can currently see it in. Making modifications to these types of classes could potentially have knock-on-effects in a lot of other unrelated places. Tread carefully”

    He’s right, the idea of OOCSS is sound but its being executed wrongly. What I do is stick everything into a component which is its own file and use BEM naming conventions. That file relies on nothing else in my css so is sandboxed off and not tied to any other “component”. I can take that file drop it right into another project and its good to go.

    I can’t necessarily do that with OOCSS. id have to take the “object” (lol) code and the component code and have both object classes and component classes on my elements. Then unpick stuff from the objects layer that I don’t require on this other project. Its like spaghetti again, no thanks.

    I don’t give a rats ass if I got “similar” css in one component to another. OOCSS is teaching us to be be BDRY (Bone DRY) which isn’t good. Being DRY has a bell curve where its good upto a point then skips down the other side to cause issues again. OOCSS is on that slope in my view.

    By simple componentizing stuff into a single file for every aspect of the UI, I can make changes to any of them and know they wont affect anything else, its gives me confidence to make changes and is ultimately easier to maintain. Stop doing “OOCSS”! Just componentize the crap out of everything in your UIs. We dont need these buzz words.

Leave a Reply

Your email address will not be published. Required fields are marked *