Writing Reusable CSS with OOCSS

Most CSS starts tidy and ends tangled. A class is written for one specific component, then copied and tweaked for the next, and before long the stylesheet is full of near-duplicate rules that all do almost the same thing. Object Oriented CSS, usually shortened to OOCSS, is a way of thinking that pushes back against this. It treats the pieces of your interface as reusable objects rather than one-off components, and it rests on a simple idea: separate the things that change independently so each can be reused on its own.

The Core Idea

OOCSS asks you to look at your design and see objects, repeatable patterns that share structure and appearance. A card, a media object with an image beside text, a grid item. Rather than styling each occurrence from scratch, you define the object once and reuse it everywhere it appears.

Making that reuse possible comes down to two separations, and they are the whole methodology in a nutshell.

The first is separating structure from skin. Structure is the layout work: how something is sized, positioned, spaced, and arranged. Skin is the cosmetic work: colours, fonts, borders, shadows, the visual treatment. These two change for completely different reasons. You might restyle every button in your brand colours without touching their layout, or rearrange a grid without changing any colours. Keeping them in separate classes means each can change without disturbing the other, and each can be reused independently.

The second is separating container from content. A container should not assume anything about what lives inside it. If a card’s layout rules are tied to the specific text and image it currently holds, that card cannot be reused for different content. Keep the container’s styles independent of its content, and the same container works in any context.

Separating Structure from Skin

In practice, this means writing classes that handle layout and classes that handle appearance, and keeping them apart.

A structure class concerns itself only with arrangement:

.grid {
  display: flex;
  flex-wrap: wrap;
  margin: -10px;
}
.grid__item {
  padding: 10px;
  flex: 1 1 200px;
}

There is not a single colour or font in there. It is pure layout, which means it can hold anything and still do its job.

A skin class handles only the visual treatment:

.card-skin {
  background-color: #fff;
  border: 1px solid #ddd;
  border-radius: 4px;
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
}

This skin knows nothing about layout. It is purely cosmetic, which means you can apply it to a grid item, a sidebar panel, or anything else that should look like a card. Because the two concerns are separate, the same skin can dress many different structures, and the same structure can wear many different skins.

Separating Container from Content

The same principle applies to the relationship between a container and what it holds. The classic example is the media object, a container that places a figure next to a body of text:

.media {
  display: flex;
  align-items: flex-start;
}
.media__figure {
  margin-right: 15px;
}
.media__body {
  flex: 1;
}

This container handles only the arrangement of a figure and a body. It does not care whether the figure is an avatar, a thumbnail, or an icon, or whether the body holds a name, a comment, or a product description.

The content inside is styled by its own separate classes:

.content-title {
  font-size: 1.5rem;
  margin-bottom: 0.5rem;
}
.content-text {
  font-size: 1rem;
  color: #666;
}

Because the typography lives in its own classes rather than being baked into the media object, the media object stays generic and the text styles can be reused outside of it. Neither depends on the other.

Composing Objects Together

The real payoff comes when you combine these small, single-purpose classes to build a complete component. Each class contributes one thing, and the element wears several of them at once:

<div class="grid grid--cards">
  <div class="grid__item card-skin">
    <div class="media">
      <img src="avatar.jpg" alt="Avatar" class="media__figure">
      <div class="media__body">
        <h2 class="content-title">John Doe</h2>
        <p class="content-text">Software Engineer</p>
      </div>
    </div>
  </div>
</div>

Look at the grid item: it carries both grid__item, which positions it in the layout, and card-skin, which gives it the card appearance. Inside, the media object arranges the avatar and the text, and the content classes style the text itself. Not one of these classes was written specifically for “a user profile card.” They are general-purpose objects composed together to produce this particular result, and every one of them is available to build the next component too.

How to Work This Way

Break your styles into small, single-purpose modules. The smaller and more focused each object is, the more places it can be reused. A class that does one thing well composes more easily than a class that does five.

Keep selectors generic and shallow. Lean on simple class selectors and avoid deep nesting or overly specific rules. A style buried under three levels of nesting is tied to one location in your markup and cannot be reused elsewhere, which defeats the whole purpose.

Adopt a naming convention that signals each class’s role. Structural objects like .grid and .media should be distinguishable from skin classes like .card-skin. A consistent convention makes it obvious at a glance what each class contributes, which is essential when composing several together.

Document your objects. Because OOCSS depends on reuse, the whole team needs to know what objects exist and how they are meant to be used. A short style guide prevents people from reinventing a card object that already exists under a different name.

Reach for reuse before writing something new. The instinct in CSS is to write a fresh class for each new component. The OOCSS instinct is to ask first whether an existing object, or a combination of them, already does the job. Reuse over rewrite is the habit that keeps the stylesheet from sprawling.

The Takeaway

OOCSS is less about specific syntax and more about a way of seeing your interface: as a set of reusable objects rather than a series of unique components. The two separations at its heart, structure from skin and container from content, exist so that the things which change independently can be reused independently. Build small, focused, generically named classes, compose them to create components, and reach for what already exists before writing more. The result is a stylesheet that grows by combination rather than duplication, which is exactly what keeps CSS maintainable as a project scales.

See you soon