OOCSS

OOCSS — Object-Oriented CSS, created by Nicole Sullivan — is built around one core principle: separate an element's structure from its skin. Structure is layout-related — dimensions, padding, positioning, how the box is put together. Skin is visual — colors, borders, fonts, backgrounds, gradients. Instead of writing one monolithic class per visual variant, you write one structural class plus separate skin classes that can be mixed onto it.

The problem without OOCSS

A common starting point is a class per button variant, duplicating the shared structural rules in every one:

CSS

.btn-primary {
  display: inline-block;
  padding: 0.6em 1.4em;
  border-radius: 6px;
  font-weight: 600;
  background: #0066cc;
  color: white;
}

.btn-danger {
  display: inline-block;   /* duplicated */
  padding: 0.6em 1.4em;    /* duplicated */
  border-radius: 6px;      /* duplicated */
  font-weight: 600;        /* duplicated */
  background: #cc0000;
  color: white;
}

.btn-outline {
  display: inline-block;   /* duplicated again */
  padding: 0.6em 1.4em;
  border-radius: 6px;
  font-weight: 600;
  background: transparent;
  border: 2px solid #0066cc;
  color: #0066cc;
}

Worked example: structure + skin

OOCSS pulls the shared structural rules into one reusable class, and keeps each visual treatment in its own small skin class:

CSS

/* Structure — shared shape, sizing, and layout. Never has color. */
.btn {
  display: inline-block;
  padding: 0.6em 1.4em;
  border-radius: 6px;
  font-weight: 600;
  border: 2px solid transparent;
}

/* Skin — visual treatment only, no layout properties */
.btn--primary {
  background: #0066cc;
  color: white;
}

.btn--danger {
  background: #cc0000;
  color: white;
}

.btn--outline {
  background: transparent;
  border-color: #0066cc;
  color: #0066cc;
}

HTML

<button class="btn btn--primary">Save</button>
<button class="btn btn--danger">Delete</button>
<button class="btn btn--outline">Cancel</button>

Why this promotes reuse

The .btn structural class is now written exactly once and reused by every variant, so changing padding or border-radius site-wide means editing a single rule instead of hunting down every variant class. New visual variants are cheap — a small skin class with only a handful of declarations, no need to redeclare layout at all. The trade-off is that every element now needs two classes instead of one, which is precisely the cost OOCSS accepts in exchange for that reuse.

Approach	Classes per element	Duplication	Ease of adding a new variant
One monolithic class per variant	1	High — structure repeated in every variant	Copy-paste an entire rule block
OOCSS structure + skin	2	None — structure defined once	Write a small skin class only

OOCSS's structure/skin split is exactly what utility classes generalize further

A structural class like .btn and a skin class like .btn--primary are themselves reusable, composable pieces. Utility-first CSS takes this idea to its logical extreme, breaking styles down into even smaller single-property classes composed directly in markup.

Structure/skin separation only pays off if you keep the split disciplined

The moment a skin class quietly includes a layout property (like padding or width), the separation breaks down — you can no longer freely swap skins onto the structural class without unexpected layout shifts. OOCSS requires the discipline to keep structural and visual concerns strictly apart, which is easy to state but easy to accidentally violate under deadline pressure.

See the modern, markup-driven evolution of composable classes: Utility-First CSS.