OOCSS — The best way to code reusable CSS in an easy way!

Comments

Start the Conversation

Object-oriented programming is the current standard in programming, why should it be any different in CSS. OOCSS allows you to create clean, reusable CSS. In this article, I’ll go over OOCSS, how to apply it and why you should. Turn your CSS markup into a lean, mean, clean, high performance styling machine! Let’s dive into OOCSS!

OOCSS

What is Object-Oriented Programming?

Object-oriented programming isn’t a new idea. It’s been around since the late 1950s starting at MIT in the environment of the artificial intelligence group. According to Wikipedia,

Object-oriented programming (OOP) is a programming paradigm that represents concepts as “objects” that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are instances of classes, are used to interact with one another to design applications and computer programs.Massachusetts Institute of Technology

OOP has become widely-used in both JavaScript and backend languages for several years now, but organizing CSS according its principles is still relatively new. In layman’s terms, OOP is the practice of making your code reusable, efficient and fast.

Why Object-Oriented CSS?

How do you scale CSS for thousands of pages? OOCSS is an answer. It’s an approach for writing CSS that’s fast, maintainable, and standards-based. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

OOCSS is not that different from other CSS methodologies like SMACSS or BEM. All of them aim to separate content from structure by placing CSS styles in reusable modular blocks of code. In fact, I usually mix SMACSS with OOCSS.

For instance, in the example below, we’ll create a OOCSS media object that describes a content block containing a fixed-size media element (e.g. image or video) along with other variable-size content (e.g. text).

Media Object Example

Base Classes

PropertyDescription
mediaWrapper for the media object
imgChild node of the media object. Generally a link, image, or flash wrapper. Will appear to the left of the .bd. Optional region.
bdMain content area for the media object, can contain any other objects. Protected. Required region.
imgExtChild node of the media object. Generally a link, image, or flash wrapper. Will appear to the right of the .bd. Optional region.

HTML

<div class="media">
	<a href="https://twitter.com/bmarshall0511" class="img">
		<img src="https://pbs.twimg.com/profile_images/917850007897649157/rNzB5n0H_400x400.jpg" alt="bmarshall0511" />
	</a>
	<div class="bd">
		<a href="https://twitter.com/bmarshall0511">@bmarshall0511</a> <span class="detail">14 minutes ago</span>
	</div>
</div>

As with any object-based coding method, the purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain.

The “Object” in OOCSS

The “object” in OOCSS refers to an HTML element or anything associated with it (like CSS classes or JavaScript methods). For example, you might have a sidebar widget object that could be replicated for different purposes (newsletter signup, ad blocks, recent posts, etc). CSS can target these objects en-masse which makes scaling a breeze.

To understand OOCSS, you need to understand it’s two main principles:

  1. Separation of Structure from Skin
    Defines repeating visual features (like background and border styles) as separate “skins” that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code.
  2. Separation of Containers and Content
    Meaning “rarely use location-dependent styles”. An object should look the same no matter where you put it. So instead of styling a specific <h2> with .myObject h2 {...}, create and apply a class that describes the <h2> in question, like <h2 class="category">.

OOCSS is not its own language. Anyone who understands CSS can easily grasp the OOCSS approach. In CSS, the “object” can be any repeating visual pattern that can be specified in snippets of code. Page elements and even groups of elements are given object classes, which are treated as single entities in style sheets. Unlike SMACSS, which gives programmers less freedom for categorizing objects, OOCSS is relatively easy to master.

Separation of Structure from Skin

OOCSS has two major underlying principles. The first is establishing a clear division between structure and skin. This allows custom skinning to be applied onto multiple page elements without affecting the structure.

The structure of an application refers to things that are “invisible” to the user such as instructions for element size and positioning. These properties include:

  • Height
  • Width
  • Margins
  • Padding
  • Overflow

An application’s skin refers to the visual properties of elements such as:

  • Colors
  • Fonts
  • Shadows
  • Gradients

In other words, the structure consists of the instructions for how things are laid out, and the skin defines what the layout looks like. OOCSS defines them separately. See the examples below:

Before OOCSS

#button {
  width: 200px;
  height: 50px;
  padding: 10px;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#box {
  width: 400px;
  overflow: hidden;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

#widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

The three elements above have styles that are unique to each, and they’re applied with the non-reusable ID selector to define the styles. But they also have a number of styles in common. The common styles might exist for branding purposes or consistency of design.

With a little bit of planning and forethought, we can abstract the common styles so the CSS would end up instead like this:

After OOCSS

.button {
  width: 200px;
  height: 50px;
}

.box {
  width: 400px;
  overflow: hidden;
}

.widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
}

.skin {
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

Now all the elements are using classes, the common styles are combined into a reusable “skin” and nothing is unnecessarily repeated. We just need to apply the “skin” class to all the elements and the result will be the same as what the first example would produce, except with less code and a possibility for further reuse.

Something to keep in mind…

When coding OOCSS, it’s important to make all styles you create as generic and adaptive as possible. A general rule of thumb is to try and never use defined widths and heights. The content should be able adapt accordingly while keeping the same look. This is true for most all styles in OOCSS.

Separation of Containers and Content

The second principle of OOCSS is the separation of containers and content. We should rarely use location dependent styles, because those styles then become locked into specific selectors. The “skin” of an object should look the same no matter where it’s located. Separating containers from content makes for a more consistent and predictable user experience. In this context, content refers to elements such as images, paragraphs and div tags that are nestled within other elements, which serve as containers. Most containers can be represented by a structure class.

For example, you can use the class combination btn-small btn-red to ensure that you see a small, red button regardless of the container it appears in so long as the structure class btn-medium and skin class btn-red are written independent of a container.

As a general rule, styles should never be scoped to particular containers. Otherwise, you’ll be unable to reuse them without applying overrides. For example, below is the standard way of setting up the elements that make up a sidebar:

#sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}


#sidebar .list {
    margin: 3px;
}


#sidebar .list .list-header {
    font-size: 16px;
    color: red;
}


#sidebar .list .list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}

Now, here are the same coding instructions with the content and containers separated:

.sidebar {
    padding: 2px;
    left: 0;
    margin: 3px;
    position: absolute;
    width: 140px;
}

.list {
    margin: 3px;
}

.list-header {
    font-size: 16px;
    color: red
}

.list-body {
    font-size: 12px;
    color: #FFF;
    background-color: red;
}

Avoiding child selectors is a good strategy for maintaining separation between content and containers. Be sure to bestow unique classes to unique elements.

What about semantics & SASS? Keep reading →

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

All comments are held for moderation. I'll publish all comments that are on topic and not rude. You'll even get little stars if you do an extra good job.

You may write comments in Markdown. This is the best way to post any code, inline like `<div>this</div>` or multiline blocks within triple backtick fences (```) with double new lines before and after.

Want to tell me something privately, like pointing out a typo or stuff like that? Contact Me.

%d bloggers like this: