There are only two hard problems in Computer Science: cache invalidation and naming things. Phil Karlton, Netscape

Naming things is harder.


There are many ways to name and structure CSS:

  • No standard (most common) — It all sort of happens at once
  • OOCSS — Object-Oriented CSS
  • BEM — Block, Element, Modifier
  • SMACSS — Scalable and Modular Architecture for CSS
  • SUIT CSS — Custom processor and framework
  • Maintainable CSS — BEM but with camel casing
  • Inuit CSS — No UI, just structural framework
  • Atomic CSS — CSS replacement for component-based frameworks (monstrosity)
  • Tailwind CSS — Everything is a utility class (bleeding eyes)

None of these are perfect. They copy, overlap, underlap, and contradict each other. Understand that each framework was created to support a particular kind of application and different development practices.

Picking one misses the point. Study and learn from them.


Even within BEM-like naming systems there are variations: Fifty Shades of BEM.

TODO - Read:

The GravDept methodology

GravDept treats almost everything as:

  • BEM components
  • Utility classes

This blend works for us because our projects have similar characteristics:

  • Responsive design and mobile-first thinking are suited to creating components before layouts.
  • Some projects write HTML from scratch.
  • Some projects inherit HTML from platforms (ex: Magento).
  • We don’t publish a monolithic design system (ex: Bootstrap, Salesforce Lightning) that other applications inherit and modify.
  • We do share architecture and copy components across projects for efficiency.

BEM provides a naming schema that’s flexible where needed:

  • Modularize class names so they’re extensible.
  • Decouple CSS from HTML (to a degree).

The BEM methodology is a better way to decouple CSS from HTML, and modularize class names so they can be extended.

Naming problems that matter

Use prefix-free naming

Some methodologies make rigid distinctions (enforced with class prefixes) between layouts, modules, components, and utilities. Example:

// Layout
.l-header {}
.l-matter {}
.l-footer {}
.l-grid {}

// Component
.c-callout {}
.c-form {}

// Utility
.u-align-center {}
.u-m-b-1 {}
.u-text-xl {}

We haven’t found that necessary.

Utilities are always self-documenting and descriptive. They rarely collide with component names. Everything else works as a BEM component if you treat it that way.

// Layout
.app-header {}
.app-matter {}
.app-footer {}

// Component
.callout {}
.grid {}
.form {}

// Utility
.align-center {}
.m-b-1 {}
.text-xl {}

Our filesystem uses folders for organization, but class naming doesn’t need to reflect this. It’s overkill.

This also smooths out

<div class="align--center text--xl m-b-1">
    Hello World!

Everything else works as a BEM component.

Starting out, if everything as a component, and it works fine.

Modifiers vs. utilities


BEM naming

GravDept BEM uses one underscore. Default BEM uses two underscores, which serves no purpose.

Why it’s better

  • Every selector has the same specificity (1) because each selector is one class.
  • Every element is defined via a block.
  • Every modifier is defined via a block or element.
  • Every class imparts some structural info without binding to exact HTML.
<div class="block block--modifier">
    <div class="block_element block_element--modifier">
// BEM (default)
.block__element {}
.block--modifier {}
.block__element--modifier {}

// BEM (GravDept)
.block {}
.block_element {}
.block--modifier {}
.block_element--modifier {}


<div class="panel panel--collapsible">
    <div class="panel_header">

    <div class="panel_body">
        <p>Lorem ipsum dolor sit amet.</p>
.panel {}                 // Block
.panel--collapsible {}    // Block modifier

.panel_header {}          // Element

.panel_body {}            // Element
.panel_body--unpadded {}  // Element modifier

Why it’s better

  • All the selectors have same specificity (one).
  • Every element is defined via a block.
  • Every modifier is defined via a block or element.
  • Each class name imparts structural info without binding to exact HTML.

Element suffixes

Always use suffixes with these elements:

.some-button {}
.some-link {}
.some-input {}
.some-form {}
.some-list {}
.some-table {}

Plurals and singulars

Prefer writing singular nouns:

.card {}

Prefer writing plural nouns to group sets of singular nouns:

<div class="cards">
    <div class="card"></div>
    <div class="card"></div>
    <div class="card"></div>