An Introduction to Object Oriented CSS

With richer interactions and media heavy pages mushrooming on the web, creating web pages, which load faster and respond well has become a challenge. Separating the content, presentation and behavior of a page using HTML, CSS and JS, is not the only thing that front-end engineers have to concentrate on nowadays. The limelight is now on the performance of the pages, cleanliness and leanness of the code within, scalability and reusability of CSS, and the semantic correctness of the markup.

There are a handful of frameworks, techniques and approaches that are built towards this goal of maintainability, scalability and reusability of CSS. Each of them is having its own pros and cons. But, this is not a stage to elaborate on all of them.

This article is an introduction to implementing the concept of ‘Object Oriented Programming’ in building CSS for high scale websites and applications, with an eye on maintainability and reusability.

What is Object Oriented CSS?

The concept of ‘Object Oriented Programming’, is widespread among developers, and forms the basic for any modern programming language. Features like data abstraction, modularity and inheritance make it a favorite in coding large-scale applications.

Object Oriented CSS, as the name suggests, is implementing the concepts of OOP in structuring and building CSS rules, which are easy to reuse, thereby reducing the loading time and increasing the performance of web pages incredibly! The key point here is, to identify, build and style modular reusable ‘objects’ in a page, and to reuse it in multiple instances by extending them with additional features wherever needed. Here an ‘object’ refers to the basic HTML markup and its CSS rules. Apparently, here, the key challenge is going to be, identifying the ‘object’ and building rules for it.

This is neither a framework nor a technology, but an approach adopted in building the rules, so as to make the code more reusable, maintainable and scalable. You may already have been making use of this concept in coding your style-sheet for years, but may not be aware of this terminology :).

A UI engineer at Yahoo (‘Nicole Sullivan’ ) coined the term. She had made a number of presentations on the topic on various big stages ( and is also included in a feature on Women in Technology.

Nicole, who has been hired by Facebook recently, for optimizing the CSS and web page performance, has been leading the way in implementing this approach in the pages for the social networking giant, and the results are to be seen. A faster loading FB, with significantly less response time! This is exactly what this approach of building CSS promises to give back. But again, like all other frameworks, this too has pitfalls and advantages which we shall discuss in detail.

Following are some key aspects in object-oriented approach to CSS building:

  1. Create a component library
  2. Separate container and content / Avoid Location dependent styles
  3. Separate Structure and skin
  4. Extend base objects using class names
  5. Stick to semantic class names

Create a component library

This is the first thing to do, while building a OO CSS framework for your application, and this is the most time consuming process too. You will have to carefully study the screens of the app, and come up with the recurring reusable UI patterns, and will have to create a library consisting of HTML markup and respective CSS rules of all such components first. This may take some initial time, as you may need to filter out the components and find out the basic structure of a component, and its variations along different screens.

E.g. For a blog, ‘metadata (Refer to the marked area in the figure below)’ will be present in multiple instances of a page. After closer scrutiny, you will come to know that, all the metadata can have the same HTML markup, and the variations can be addressed using CSS (the font size, color, margin and padding are different in each of the occurrences of metadata component). Select a markup, as a base structure, in which you can accommodate majority of the elements that possibly can come in the particular component.

In our example our basic structure of the ‘metadata’ component will be:

Base Markup

<p class=”metadata”><a>Author name</a>commented on<a>21-02-2010</a>@</p>

Base rule

.metadata{font-size:1.2em; text-align:left; margin:10px 0;}

Thus, ‘metadata’ can be now independently used within any other element in the markup, and will have a consistent look and feel, irrespective of where it is used. But as we can see in the figure above, there are multiple variations of the component. This we will tackle using CSS, and will be discussing in the following points.

This way, figure out all the reusable components, and create rules and markup, and group them separately in the CSS file. (It’s even fine to create a separate CSS for the component library, and then merge it with others later during deployment.)

Separate Content from Container / Avoid location dependent styles

This is one of the primary requirements of following an OO approach to building CSS files. The core idea here is to consciously differentiate the rules of containers and the content that comes within them, so that content can be plugged into any containers irrespective of their parents.

Often while building large-scale CSS rules there will be instances where a single component will be appearing differently in various instances, when put in different containers. One of the solutions adopted by front-end engineers, for addressing this problem was to assign location dependent selectors to that particular component.

E.g. With reference to the example used in the previous point, where there are multiple variations of the same component – ‘metadata’, each instance can be given location dependent rules by combining the base class ‘metadata’ with the relevant classes/IDs for the containers. i.e.,

‘metadata’ in a blog post can be styled as: .post .metadata{overriding rules}
‘metadata’ in a comment can be styled as: .comment .metadata{overriding rules}
‘metadata’ in a comment can be styled as: .comment .metadata{overriding rules}

The OOCSS approach advocates avoiding this type of usage. Instead extend the base class by adding more classes, thereby extending the attributes of the base component to match the variation. We shall discuss the concept of extending the base class in the following points.

Separate structure and skin

In the first point ‘Creating component library’, we discussed the importance of identifying reusable components, and building base classes and base structures for them. While creating those base rules, an important thing to keep in mind is to separate the structure and skin. In other words, while defining a base class in the component library, we should not create skin-level rules, like width, height, background images, border styles, etc, that can make the component more specific to a certain container.

E.g. For our base class, ‘metadata’ with the following rule

.metadata{font-size:1.2em; margin:10px 0;},

Adding more skin-level rules as below,

.metadata{font-size:1.2em; margin:10px 0; <strong>width:500px; background-color:#efefef; color:#fff;</strong>},

can make it more of a specific component than a generic one, thereby making it difficult to reuse it in many other containers, which would need it to be rendered in a different ‘skin’. Also another danger of not separating structure and skin will be the ‘Specificity war’.

Extend base objects using class names

As discussed in the second point ‘Separate content from container’, avoiding the usage of contextual selectors will make the content independent from their parent containers and hence will be truly usable across the application. So how do we instantiate the variations of the same object in different containers? What is the solution? Well here comes the concept of extending the base ‘object’ (again another term coined by Nicole Sullivan), by adding more class names to it depending on the context, rather than tightly coupling the object with the class names of the containers in which it is to be placed.

E.g. In the first figure of the ‘metadata’ object, where the same object needs to be rendered differently in various containers,

The HTML markup of each of them will look like:

<p class=”metadata commentmetadata”><a>Authorname</a>commented on<a>21-02-2010</a>@</p>
<p class=”metadata postmetadata”><a>Authorname</a>commented on<a>21-02-2010</a>@</p>
<p class=”metadata authorlistmetadata”><a>Authorname</a>commented on<a>21-02-2010</a>@</p>

The CSS rules will be:

.metadata{font-size:1.2em; margin:10px 0;}
.commentmetadata{font-size:1em; margin:0 0 10px 0; color:#063070; }
.postmetadata{ color:#063070; }
.authormetadata{ color:#fff; }

This is a very simple demonstration, to comprehend the concept of implementing OO programming. As the size of the app becomes larger, the UI patterns will become more complex, and there lies the actual challenge and advantage of using such an approach.

Stick to semantic class names

A challenge in building CSS for high-scale web applications is to logically come up with meaningful class / ID names matching with the context and moreover making sure, they are reusable and still make sense. With the concept of ‘extending’ base objects, it’s easy to fall into the practice of creating ‘presentational class names’. Some easy examples are ‘leftCol’, ‘redText’, ‘midCol’, ‘bigText’, ‘bolderText’ etc. Such class names are not reusable and are a hindrance to scalability.

Always stick to logical and semantic class names relating to the logical meaning of the component, rather than its presentational meaning. It means, instead of giving the text block with a yellow background color, the class name ‘yellowText’, ‘notification’ would be a more sensible name, as it is a notification element that pops out to notify some activities within the system.

Pros and Cons?

Following such an approach of building CSS has its own pitfalls and advantages

Here are a few cases, where adopting such a framework ‘may’ backfire:

  1. OOCSS is suited to really large websites / application which are filled with reusable components. It may not give desired results in smaller websites and applications. So decide sensibly depending on the size of the work in hand
  2. If not smartly used, creating the component library can turn out to be a mess, and become a maintenance nightmare for other coders
  3. Documentation is a must. Each block of code should be clearly commented out with the right points for other coders to absorb the concept, which otherwise can become too tedious in case of a knowledge transition

Some obvious advantages of adopting this approach are:

  1. Less lines of CSS code
  2. Cleaner HTML markup, with logically sensible class names and hierarchy
  3. Semantic markup, means more SEO friendly pages
  4. Far better page optimization, with much faster loading times, since most of the components are reused
  5. Scalable markup and CSS code, where more components can be added into the library without disturbing other components, as the base objects are independent of any other containers
  6. Easily theme-able layouts, since changes to the base object can completely change almost the whole presentation layer instantly

Courtesy & Resources for all the icon resources

Ranjith Kumar

A User Experience designer with specialized experience in front-end engineering, i have over time developed a strong passion in being associated with product-based teams. The unified goal and challenges that a product's life cycle offers is simply unbeatable! For me, proficiency in tools takes the back seat when it comes to User Experience Design, and i believe one has to be passionate and equally agile to be a key part of the team. I bring to the table the diverse hands-on experience on various facets of experience design, and have played key roles in the team bridging the gap between design, dev and biz groups within product teams. My vision is to be the key hand behind the UX design of a world-class product in a team of passionate and uber-smart techies and designers! Specialties: Information Architecture, Wireframing, Heuristic Evaluation, Web standards, Interaction design, Semantic markup, OO CSS, Usability Review

15 Smart Tools To Help You Build Your Freelance Business

Discover the awesome tools we use in making our clients comfortable and happy in learning new things every day.

Download Now


  1. says

    of course it is a great efforts for you to create such informative website. your article is very interesting and useful for user who is interested about the topics. I hope you will continue your process.

  2. Joao Carlos says

    If you have access to a CSS pre-compiler such as SASS(sass or scss), STYLUS, etc. I think a much better way would be to divide your components by type, and make some generic rules, then divide them by specific name.

    // ============== Vars =====================
    $total-width : 960px;
    $column1-width : $total-width/6.357;
    $column3-width : $total-width/4.423;
    $column2-width : $total-width - ($column1-width + $column3-width);
    $subheader-height : 159px;


    $picwidth: 38px;
    width: $column3-width - ($padding*2) + 2px; //2px for perfection
    height: $subheader-height - $padding*2;
    ul{ width: $width - $padBox - 0px; //2px for border
    height: ($picwidth + $padPic)*2 ;
    display: inline-block;
    @include debug;

    Debug is also another nice concept, it basically its just a mixin that puts background-color:red; that I can auto-search for to remove from deployment version quickly and easily by commenting out the code inside the mixin, effectively making it empty and not display in the deployment, or turn on in debug mode.

    • Joao Carlos says

      Notice: The ratios on top ( i like ratios), the comments and ignorable ” – 0px;” with comments inplace, this clearly displays intention and if i quickly need to add a border, i can just change the 0px to something else and the whole thing would work straight, without having to test to make sure i did what i actually meant to do, also, the comments are much easier to find if you dont put a ton of them, if your css and variable names are clear, you shouldnt need too many comments.

      The math formulas for size display much more clearly the intention and thought process behind the values you input, I hate having a CSS file full of diferent pixel values where you dont know where they came from.

      Also notice the UL and LI styles are contained inside the #thumbnailPicBox so they are rendered much in way of “OO-CSS” the article was based on, however, they are much more succinct (less verbose) and the indentation (that was broken by this comment box) clearly shows they should only be applied to this “object”.

      This pre-compilers (source-to-source translation in reality), support a @extend feature, that you can apply directly, and that will “copy” (copy/merge, they are smart) the styles in a child-inherits-parent fashion that drastically reduces your manually typed css code length. If you are worried about final file size (LOC), they also analise your source files and apply styles in such a way as to not have duplicated code anywhere by use of common taggin (more tags per block of css) and inheritance and also by “ugly-fying” and merging all files in one big file, thus results in much much smaller file sizes and page requests.

  3. Andrew says

    Thanks this is a nice intro for OOCSS, I found the breakdown of extending classes particularly interesting. Would it not be more semantic and scalable if the extensions were of the form:

    Comment info
    Post info
    Author info

    .metadata{font-size:1.2em; margin:10px 0;}
    .metadata.comment{font-size:1em; margin:0 0 10px 0; color:#063070; }{ color:#063070; }{ color:#fff; }

    • Andrew says

      Sorry that’s meant to read:

      Comment info
      Post info
      Author info

      .metadata{font-size:1.2em; margin:10px 0;}
      .metadata.comment{font-size:1em; margin:0 0 10px 0; color:#063070; }{ color:#063070; }{ color:#fff; }

  4. says

    Seems like it’d just be a pain in the ass, and more trouble than it’d be worth, and make your CSS file ten miles long, because you’d be continuously adding new classes to other classes, and overriding old things with new things.

    I prefer the simplistic method of just styling things direct, so I don’t have to remember all those new classes I created to extend the old ones. This way I don’t have a bunch of classes overriding other classes, and my CSS files are shorter, and more “to-the-point.”

  5. Jason says

    Interesting concept. I believe I have been using it to some extent for a few years now anyway, and I never knew it had a name. It surely seems that you could make a CSS framework with this concept fairly easily. Now that I have a bit more understanding of how and why, I might be able to put it to better use than I have been over the years.

  6. Antown says

    Of course very beautiful it turns out, however, whether the so-complicate things? I prefer the old CSS.

  7. PalSingh says

    Very informative article… i have been using this concept.. but this information will help me to improve and make it more logical

  8. Jason says

    Wow, never thought of additional class selectors as extending objects (as in OO). This made me look at this in a whole new way! It makes sense that the idea of “classes”, being reusable instantiated objects which can extend other classes, fits within the OO paradigm.

  9. says

    Thanks for the awesome tutorial. Pretty cool technique. I would like to use the technique in my ongoing project. I will share again my experience.

    Thanks again.