First Look: Object Oriented CSS

    Kevin Yank

    In October, I’ll speak at Web Directions South 2009 in Sydney about CSS Frameworks. One of the main questions I will answer in my talk is whether or not you should use a CSS Framework in any given project. Since the alternative is writing your own CSS styles from scratch, I’m researching some of the latest thinking on hand-coded CSS.

    Object Oriented CSS for high performance web applications and sites

    One prominent voice in this arena is Nicole Sullivan, who has developed a methodology called Object Oriented CSS (OOCSS). She outlined this approach to writing CSS at Web Directions North 2009, and the 48-minute video is available.

    Sullivan is a talented and engaging presenter, but I found the video a lot to take in all at once. Since watching it, I have applied the principles of OOCSS to an internal project here at SitePoint, and I feel like I have a better grasp on what it’s all about.

    A Change of Perspective

    Just another framework? Think bigger: “OOCSS isn’t really a framework … but a way of writing scalable, sane, maintainable CSS,” writes Sullivan. Sullivan uses and recommends a grid framework like Yahoo!’s YUI Grids, but you’re free to write your layout styles from scratch using OOCSS principles if that’s your thing. But OOCSS applies equally to the work you do after you have implemented your site’s layout, as you design the blocks and content that slot into your layout.

    Most web designers tend to write CSS code so that it requires as little extra markup (whether <div> or <span> tags or class attributes) as possible. Fundamentally, adopting OOCSS is making a mental shift towards easy maintenance and reuse of your styles, even if it means writing extra HTML markup.

    OOCSS methodologies help you to look beyond your immediate design goals and organize your code so that adding new site content that reuses the same styles in the future becomes trivial. With OOCSS, adding a new type of page to your site should mean that there’s no need to create additional CSS styles or selectors. New page types should be able to reuse existing CSS styles as much as possible.

    When designing a site with OOCSS, you must break your design into reusable components, which OOCSS calls objects. Each component is a fixed HTML structure, to which you apply a set of CSS rules that control its layout (in OOCSS parlance, the structure), and another set of CSS rules that control its appearance (the skin). That component can then contain arbitrary HTML content: paragraphs, lists, tables, and so on, all of which is styled independently of the container in which it appears.

    This last point is crucial. Under OOCSS you must avoid what Sullivan calls “location-based selectors” — that is, styles that affect content differently, depending on the part of your site in which it appears. If you want, say, a list to look different in a particular part of your site, you should add a class attribute to it and apply the styles based on that attribute. This ensures that the list can be lifted out and reused elsewhere on the site, with its style remaining intact.

    An Example in Code

    Let’s say every page of your site had a sidebar, the code for which looked like this:

    <div class="sidebar">
      …sidebar content…

    Now, let’s say you had a set of pages where you wanted this sidebar styled a little differently — say with a different background color to highlight a sale on certain products. You would probably also want to make changes to some other elements of those pages because of this sale, too.

    Traditionally, your approach to this might be to add a class to your page’s <body> tag:

    <body class="onsale">

    “Brilliant!”, you would think. “Now I can make all my style adjustments for this sale without making any further changes to my HTML code!” Then you would set about writing a bunch of style rules like this one:

    body.onsale .sidebar {
      background-color: #FFA500;

    The approach recommended by Object Oriented CSS is quite different. Instead of a single class applied to the body of your page, you would create a new class for each type of element that you wanted to change for the sale. Here’s what the sale style for the sidebar might look like:

    .onsalesidebar {
      /* extends .sidebar */
      background-color: #FFA500;

    This class is said to extend the existing class that describes the standard style for the element. You then apply it in addition to the existing (base) class:

    <div class="sidebar onsalesidebar">
      …sidebar content…

    Now, a content editor can confidently copy and paste this sidebar code into another page of your site, or even a brand new page, and know that it will be displayed with the same styles applied. The same principles apply to the styling of the content within this sidebar.

    The guidelines for OOCSS actually recommend a considerably more complex HTML structure for reusable components like this, which enable more intricate styles to be applied to them — including rounded corners and border effects — but this simple example effectively demonstrates the fundamental principles behind OOCSS.

    What’s the Point?

    Sullivan works at Yahoo, where her primary focus is on improving web site performance. Aside from the copy-and-paste reusability of styled HTML content and component blocks, OOCSS claims to offer significant benefits in performance.

    By prioritizing the reuse of CSS styles across your site, OOCSS results in considerably smaller CSS files, but slightly larger HTML files. This trade-off is desirable because the size of your CSS files directly influences the amount of time that the browser displays a blank page while your site loads. Smaller CSS means less time spent looking at a blank page. Once your CSS has loaded, your site’s HTML content is displayed progressively as it loads. The result of this trade-off, then, is greater perceived performance, even if the total load time is slightly longer.

    Furthermore, by avoiding location-based selectors, you reduce the amount of work that the browser has to do to determine the actual appearance of any given element on the page. Especially on mobile browsers, but even on the desktop, this can produce significant performance gains.

    Is It Worth It?

    If you’re lucky enough to be the only front-end developer working on a project, you might like to take the OOCSS principles for a spin. Where the reusability benefits of OOCSS really shine, however, is when working in a team environment.

    Senior front-end designers can define the reusable structures for the site. Visual designers can apply attractive CSS skins to those structures. Content editors can write the content that slots into those structures with confidence, knowing that only the styles they expect will be applied to the content they write.

    Coaxing an entire team to jump aboard the OOCSS bandwagon can be a significant undertaking, however, and that’s the point I’m at here at SitePoint. Having applied OOCSS principles to a little project on my own, I now have to decide if it’s worth bringing this to the SitePoint design team.

    What do you think? Are the benefits of OOCSS worth the extra discipline required to adopt it, or is CSS complicated enough already?