🏛️ CSS Organization Methodologies (BEM, SMACSS, OOCSS)

Why CSS Needs Architecture

A small stylesheet is easy: you write a few selectors and everything works. But CSS was designed for documents, not for the sprawling component-based apps we build today. As a project grows past a few hundred lines, the language's own features start to work against you:

• The global namespace — every selector you write is visible everywhere. Two developers who both add a .button rule will silently clobber each other.
• Specificity conflicts — when a style won't apply, the tempting fix is a more specific selector, which starts an escalating "specificity war" that ends in !important.
• Duplication — without shared conventions, the same visual pattern gets rewritten in five slightly different ways.
• Fear of deletion — nobody dares remove a rule because they can't tell what it still affects. The file only ever grows.

💡 A useful analogy: A methodology is like a building code. It doesn't change what bricks and beams can do — it gives everyone on the crew a shared, predictable way to assemble them so the structure stays sound as it grows and as new people join.

None of the three approaches below is a framework or a tool you install. They are conventions — agreements about how you name classes and where you put rules. That's exactly why they're valuable: they cost nothing but discipline, and they pay off most on the projects that need them.

BEM — Block, Element, Modifier

BEM, developed at the Russian search company Yandex, is first and foremost a naming convention. It answers one question: what should I name this class? The answer is a strict pattern that makes the relationship between a component and its parts visible right in the markup.

Block

A block is a standalone component that means something on its own and could be moved anywhere on the page. Blocks are your top-level building pieces.

/* Blocks — independent, reusable components */
.header { }
.menu { }
.search-form { }
.button { }

Element

An element is a part of a block that has no meaning outside of it — like the legs and seat of a chair. Elements are joined to the block name with two underscores.

/* Elements — belong to a block, joined with __ */
.menu__item { }
.search-form__input { }
.button__icon { }

Modifier

A modifier is a flag that changes a block or element's appearance, state, or behavior. It's joined with two hyphens, and it's always applied alongside the base class, never instead of it.

/* Modifiers — variations, joined with -- */
.button--primary { }
.button--large { }
.menu__item--active { }

BEM in Practice

Here is a card component written end to end. Notice how you can read the structure of the HTML from the class names alone, without seeing the markup nesting.

<article class="card card--featured">
  <header class="card__header">
    <h2 class="card__title">Article Title</h2>
    <p class="card__meta">Posted January 1, 2026</p>
  </header>
  <div class="card__content">
    <p>Article content goes here…</p>
  </div>
  <footer class="card__footer">
    <button class="card__button card__button--primary">Read More</button>
    <button class="card__button card__button--secondary">Save</button>
  </footer>
</article>

/* Block */
.card {
  background-color: var(--card-bg);
  border-radius: 8px;
  box-shadow: 0 2px 4px rgb(0 0 0 / 0.1);
  padding: 20px;
}

/* Block modifier */
.card--featured {
  border-left: 4px solid var(--primary-color);
  box-shadow: 0 4px 8px rgb(0 0 0 / 0.2);
}

/* Elements */
.card__header { margin-bottom: 15px; border-bottom: 1px solid var(--border-color); }
.card__title  { margin: 0 0 5px; font-size: 1.5rem; }
.card__meta   { color: var(--text-light); font-size: 0.875rem; }
.card__footer { display: flex; justify-content: flex-end; gap: 10px; }

.card__button {
  padding: 8px 16px;
  border: none;
  border-radius: 4px;
  cursor: pointer;
}

/* Element modifiers */
.card__button--primary   { background-color: var(--primary-color); color: #fff; }
.card__button--secondary { background-color: transparent; color: var(--primary-color); border: 1px solid currentColor; }

SMACSS — Categorizing Your Rules

SMACSS (Scalable and Modular Architecture for CSS), created by Jonathan Snook, is less about naming and more about sorting. It says: every CSS rule you write falls into one of five categories, and if you file each rule under the right category, your stylesheet stays navigable no matter how big it gets.

1. Base

Defaults applied directly to elements — no classes. This is your reset and your baseline typography.

body { margin: 0; }
a { color: var(--primary-color); text-decoration: none; }
a:hover { text-decoration: underline; }

2. Layout (prefix l-)

The major structural regions of a page — header, sidebar, main, footer, grid. SMACSS suggests an l- prefix so layout rules are easy to spot.

.l-header { position: sticky; top: 0; z-index: 100; }
.l-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  gap: 20px;
}

3. Module

The reusable components that live inside layouts — cards, buttons, navs. This is where the bulk of your CSS lives. Child parts get module-prefixed names (.card-title, not a bare .title) to stay scoped.

.card { }
.card-title { }
.btn { }
.btn-primary { }

4. State (prefix is- / has-)

How a module looks in a particular state, usually toggled by JavaScript. States are meant to override, so they read clearly: is-active, is-hidden, has-error.

.is-hidden { display: none; }
.nav-item.is-active { font-weight: 700; }
.field.has-error { border-color: var(--warning-border); }

5. Theme

Optional. Color schemes and skins that can be swapped — most naturally implemented today with CSS custom properties (the subject of the next lesson).

.theme-dark {
  --bg: #121212;
  --text: #f8f8f8;
  --accent: #bb86fc;
}

css/
├── base/      reset.css, typography.css
├── layout/    grid.css, header.css, footer.css
├── modules/   nav.css, card.css, button.css
├── state/     states.css
├── theme/     dark.css, light.css
└── main.css   imports all of the above

SMACSS is more flexible and less prescriptive than BEM, which is its strength and its weakness: you get freedom, but you also have to make more judgment calls about which bucket a rule belongs in. Many teams pair the two — SMACSS categories for organization, BEM naming inside the module bucket.

OOCSS — Structure vs. Skin

OOCSS (Object-Oriented CSS), pioneered by Nicole Sullivan, is a set of principles rather than a naming scheme. Its goal is maximum reuse, achieved through two rules of separation.

1. Separate structure from skin

Split the properties that define shape (display, padding, dimensions) from the ones that define look (color, border, background). Now one structural class can wear many skins.

/* ❌ Structure and skin welded together — duplicated for every color */
.button-green {
  display: inline-block;
  padding: 5px 15px;
  border-radius: 3px;
  background-color: green;
  color: white;
}

/* ✅ Structure once, skins as needed */
.btn { display: inline-block; padding: 5px 15px; border-radius: 3px; }
.btn-green { background-color: green; color: white; }
.btn-blue  { background-color: blue;  color: white; }

2. Separate container from content

Style an element by its own class, never by where it happens to sit in the DOM. A heading should look the same whether it's in the sidebar or the footer.

/* ❌ Location-dependent — the same heading is defined twice */
.sidebar h3 { font-size: 16px; color: #333; }
.footer h3  { font-size: 16px; color: #fff; }

/* ✅ Class-based — the object is portable */
.heading { font-size: 16px; line-height: 1.2; }
.sidebar { color: #333; }
.footer  { color: #fff; }

Followed to its conclusion, OOCSS produces small single-purpose classes you compose in the HTML — which is exactly the idea behind utility frameworks like Tailwind and the reason Bootstrap's .btn / .btn-primary split looks the way it does.

<button class="btn bg-primary text-light shadow-sm">Follow</button>

Comparing & Combining Them

These three aren't rivals — they solve different problems and layer together naturally.

The hybrid most teams actually use

In practice you rarely pick just one. A common, effective blend: organize files with SMACSS categories, name your components with BEM, and add a layer of OOCSS-style utility classes for one-off tweaks.

/* Base (SMACSS) */
a { color: var(--primary-color); }

/* Layout (SMACSS naming) */
.l-header { position: sticky; top: 0; }

/* Module with BEM naming */
.card { padding: 20px; }
.card__title { font-size: 1.5rem; }

/* Utility / skin classes (OOCSS) */
.text-large { font-size: 1.25rem; }
.mt-4 { margin-top: 1rem; }

Hands-on Exercise

/* Before — unstructured */
.stat-card { background: #fff; border-radius: 8px; padding: 20px; }
.stat-card.negative { border-left: 4px solid #f44336; }
.stat-value { font-size: 28px; font-weight: bold; }
.stat-label { color: #777; font-size: 14px; }
.stat-change { font-size: 14px; font-weight: bold; }
.stat-change.positive { color: #4caf50; }
.stat-change.negative { color: #f44336; }

/* After — BEM */
.stat-card {
  background: var(--card-bg);
  border-radius: 8px;
  padding: 20px;
}
.stat-card--negative { border-left: 4px solid var(--warning-border); }

.stat-card__value  { font-size: 28px; font-weight: 700; }
.stat-card__label  { color: var(--text-light); font-size: 14px; }
.stat-card__change { font-size: 14px; font-weight: 700; }
.stat-card__change--up   { color: var(--success-border); }
.stat-card__change--down { color: var(--warning-border); }

<div class="stat-card">
  <div class="stat-card__value">$12,345</div>
  <div class="stat-card__label">Revenue</div>
  <div class="stat-card__change stat-card__change--up">+12.5%</div>
</div>

<div class="stat-card stat-card--negative">
  <div class="stat-card__value">$5,432</div>
  <div class="stat-card__label">Expenses</div>
  <div class="stat-card__change stat-card__change--down">+2.7%</div>
</div>

Best Practices

Summary & Quiz

📚 Further Reading

• getbem.com — the BEM methodology
• SMACSS by Jonathan Snook
• CSS-Tricks — BEM 101

🚀 What's Next?

You've seen SMACSS's "Theme" category and OOCSS's skin classes hint at swappable values. Next we'll make that concrete with CSS Custom Properties and Variables — the native, dynamic way to store design tokens and power theming.