A Practical Guide to the BEM CSS Naming Methodology

You are here because a selector you wrote last month is now losing to a selector someone else wrote last week, and the fix you are about to apply, adding an ID, nesting one more level, throwing in !important, is exactly how the war escalates. This BEM CSS methodology guide is the ceasefire agreement. BEM, which stands for Block, Element, Modifier, is a naming convention invented at Yandex and published as the BEM methodology specification on bem.info. It is not a browser feature, not a library, not a preprocessor. It is a discipline for naming classes so that every selector has exactly one level of specificity, no matter how deep the component sits in the DOM. The payoff is that the cascade stops being a weapon. You write .card__title, not .card .content .inner .title, not #main .card > div > h3. The specificity of every BEM class is one class: (0,1,0). That single fact ends most specificity wars before they start.

What BEM Actually Protects Against

BEM exists because unscoped CSS in a global namespace has three failure modes that every working front‑end developer has hit.

Specificity Wars

The first is the specificity war: one developer writes .card .title { color: red; }, another writes .product-card .title { color: blue; }, and the winner is whichever selector has more classes or IDs, not whichever one is semantically correct. The loser then adds .card .product-card .title–special, the cascade becomes a pile of increasingly specific selectors, and any change requires touching five files to find out which rule actually wins.

Dead CSS

The second failure mode is dead CSS. When selectors are nested and scoped by context, nobody knows whether #sidebar .widget .button is still used anywhere. The selector reach is unknown, so nobody dares delete it. The stylesheet grows, the bytes grow, and the page pays for rules that no longer match anything. BEM’s flat class names make reach obvious: if .button–primary appears nowhere in the markup, delete it. No archaeology required.

Rename Paralysis

The third failure is rename paralysis. In a global namespace, a class named .title could be styled by any rule on any page. Changing it to .subtitle means auditing every stylesheet, every template, every inline style. BEM scopes the name to the block: .card__title cannot conflict with .sidebar__title because the block name is part of the class. Renaming .card__title to .card__heading touches only the card component’s own files. That is the containment BEM provides without any browser support, since it is purely a naming convention.

Here is the same card component written two ways. First, the unscoped nested version that starts the war:

/* Nested, unscoped, specificity (0,2,0) for the title */
.product-card .content .title {
  font-size: 1.25rem;
  color: #333;
}
.product-card .content .title:hover {
  color: #0066cc;
}

Now the BEM version, with every selector at the same flat specificity:

/* BEM: each class is (0,1,0), no nesting */
.product-card__title {
  font-size: 1.25rem;
  color: #333;
}
.product-card__title:hover {
  color: #0066cc;
}

The nested version wins over any single-class rule on .title because it carries two classes. That forces every subsequent override to carry at least two classes or an ID. The BEM version never escalates: the hover rule is one class, the base rule is one class, and source order decides which wins when they conflict. You can read the whole component’s CSS in one file and know exactly what it does.

BEM Naming Convention CSS: The Three Parts

The BEM naming convention CSS uses three building blocks. A block is a standalone component: .card, .button, .modal. An element is a part of a block that has no standalone meaning: .card__title, .card__image, .button__label. The double underscore separates block from element. A modifier is a variation of a block or element: .card–featured, .button–primary, .card__title–large. The double hyphen separates the name from the modifier value.

The Yandex specification, not any blog summary, defines these rules. The block name is the namespace. Elements use the double underscore and never appear without their block. Modifiers use the double hyphen and always accompany the base class; you never write .card–featured without also writing .card in the same element’s class list. The spec is strict about this because a modifier alone carries no context: it is a variation of something, and that something must be present.

Here is the card component in full, with block, element, and modifier in the markup:

<div class="card card--featured">
  <h3 class="card__title card__title--large">Summer Sale</h3>
  <p class="card__text">All sandals 30% off until Sunday.</p>
  <button class="card__button card__button--primary">Shop now</button>
</div>

And the CSS that styles it, with no nesting and no selectors deeper than one class:

.card {
  padding: 1rem;
  border: 1px solid #ddd;
  border-radius: 0.5rem;
}
.card--featured {
  border-color: #f0a500;
}
.card__title {
  font-size: 1.25rem;
  margin: 0 0 0.5rem;
}
.card__title--large {
  font-size: 1.5rem;
}
.card__text {
  line-height: 1.5;
}
.card__button--primary {
  background: #0066cc;
  color: #fff;
}

Every rule here has specificity (0,1,0). The modifier rules and the base rules are equal in the cascade, so source order decides: put the modifier after the base and you are done. You never need to know how many classes an ancestor has, because ancestors are irrelevant to the selector.

Block Element Modifier CSS: Where It Bends

Block element modifier CSS works best for self-contained UI components: cards, buttons, form fields, nav bars. It fails when you try to style global concerns, layout grids, typographic scales, utility spacing, because those are not blocks with elements. A utility class like .text-center is not a block; it is a single-purpose rule that composes with anything. BEM does not forbid utility classes, but it does not name them either. The community convention is to keep utilities separate and let them sit alongside BEM classes, which is how .card__title–large and .u-text-large can coexist without conflict.

Multi-Element Modifiers

Where BEM bends is in modifiers that affect multiple elements. A featured card might change the title colour and the button background. Writing .card–featured .card__title and .card–featured .card__button reintroduces nesting and specificity (0,2,0). The spec’s answer is to make the modifier live on each element: .card__title–featured, .card__button–featured. That is verbose, and it is the cost of flat specificity. If you find yourself writing .card–featured .card__title, you have left the spec and entered the specificity war again.

Where BEM Does Not Help

The failure case is inheriting a codebase where someone already wrote the nested version. You cannot retrofit BEM without renaming classes in markup and CSS simultaneously, and that is exactly the rename paralysis BEM prevents. So the practical move is to isolate the new component: write the new block in BEM, leave the legacy nested CSS alone, and let the cascade do its work. BEM fights specificity by never adding to it, not by overriding what is already there.

CSS Specificity Management BEM: The Numbers

CSS specificity management BEM relies on a unitless triple (a, b, c). An ID counts as (1,0,0), a class counts as (0,1,0), and an element counts as (0,0,1). BEM keeps every selector at exactly (0,1,0), which means no selector can ever beat another on specificity grounds. The cascade then reduces to source order: later rules win over earlier ones at equal specificity. That is a rule you can hold in your head, and it is the whole point.

To see why this matters, write a nested selector that accidentally reaches three levels deep: .product-list .product-card .content .title. That is (0,4,0). Any BEM rule on .product-card__title at (0,1,0) loses to it, no matter where it appears in the stylesheet. The only way to win is to add more classes, and then the next developer adds more, and the war escalates. BEM prevents the first escalation by never letting a selector reach that depth. It is not magic; it is a rule about how many classes you are allowed to stack.

The Cost of Flat Specificity

The cost is repetition. You write .card__title instead of .card .title, and you write .card__button–primary instead of .card .button.primary. That is more characters in the source, but gzip and brotli exploit repetition, so the compressed payload difference is small. The real win is in maintenance: a selector like .card__title is self-documenting, has a known reach, and cannot be accidentally matched by markup outside the card block. The bytes you save in debugging time and dead-CSS removal far outweigh the extra characters in the file.

BEM vs Scoped Styles: What Native @scope Replaces

BEM vs scoped styles is not a fight; it is a timeline. BEM was invented in the late 2000s because the browser gave you no way to limit a selector’s reach to a DOM subtree. The naming convention was the patch. In 2023, the CSS specification shipped @scope, which does the containment in the browser rather than in the class name. With @scope, you write the styles inside a scope that is limited to a subtree, and the selectors inside do not leak out.

Here is the same card component styled with @scope, no BEM classes required:

@scope (.product-card) {
  .title {
    font-size: 1.25rem;
    color: #333;
  }
  .title:hover {
    color: #0066cc;
  }
}

The .title selector here only matches elements inside a .product-card ancestor. It cannot leak out, and it cannot be overridden by a .title rule outside the scope unless that rule is more specific or appears later in an unlayered context. @scope provides DOM-tree containment without the naming convention overhead. You do not need .product-card__title; you need .product-card as the scope root.

What @scope Does Not Do

@scope does not manage specificity within the scope. A nested selector inside the scope still has higher specificity than a single class. And @scope does not control cascade priority across scopes; that is the job of @layer. So BEM’s flat-specificity principle remains valuable inside @layer declarations: if you layer your component styles, BEM class names ensure that no rule inside a layer can beat another rule in the same layer on specificity grounds. The browser then decides between layers by ordinal position, not by selector weight.

The practical choice is either/or for new code: use @scope for containment and keep selectors short, or use BEM for containment and keep selectors flat. Mixing the two is redundant. The fallback for @scope is BEM, because BEM works in every browser that has ever shipped CSS. No @supports guard is needed for a naming convention.

@layer: Where BEM’s Flat Specificity Still Earns Its Keep

@layer lets you declare explicit priority buckets for the cascade. You write @layer base, components, utilities; then you put your styles inside each layer. Unlayered styles always win over layered styles, and among layers, the later layer wins. Specificity within a layer does not escape the layer, which means a (0,3,0) selector in the base layer loses to a (0,1,0) selector in the components layer, regardless of source order.

This is where BEM’s flat specificity becomes a feature rather than a constraint. If every component rule is (0,1,0), then within the components layer, source order is the only tiebreaker. You can reorder rules freely without worrying about one component’s nested selector beating another’s. The layer handles cross-component priority; BEM handles within-component predictability.

@layer base, components, utilities;

@layer components {
  .card__title {
    font-size: 1.25rem;
  }
  .card__title--large {
    font-size: 1.5rem;
  }
}

@layer utilities {
  .u-text-large {
    font-size: 1.75rem;
  }
}

Here the utility layer wins over the components layer when both target the same element, regardless of the fact that .u-text-large is a single class. The layer order is explicit. Inside the components layer, .card__title–large beats .card__title on source order. No specificity math required.

The Failure Case for Layers

The failure case is placing @layer after @import rules that inject styles into unlayered positions. Unlayered styles always win over layered styles, so if a third-party stylesheet is unlayered, it beats everything you have layered. The fix is to wrap the third-party import in a layer: @import url(‘theme.css’) layer(vendor);. Do that before you write any of your own layered rules. If you forget, the cascade silently ignores your layer order, and you will spend an hour wondering why your component styles are losing.

The Yandex Specification: What It Actually Says

The BEM methodology specification on bem.info, maintained by Yandex, defines the naming rules precisely. It says an element is always part of a block, never standalone; a modifier changes the appearance or behaviour of a block or element; and the block name is the namespace for all its elements and modifiers. The spec also insists that a modifier cannot be used without the block or element it modifies. Mistake 1 is writing .card–featured alone in the markup without .card. Mistake 2 is writing .card__title–large in the CSS without also defining .card__title. The spec requires both the base and the modifier so that the cascade has a stable anchor.

The spec does not say anything about nesting selectors. It is a naming convention, not a style rule about CSS structure. You can write BEM class names and still nest .card__title inside .card in your preprocessor, but then you reintroduce the specificity you avoided. The spec’s intent is flat selectors; the naming convention only makes flatness possible, it does not enforce it.

What the Spec Does Not Cover

BEM does not cover global layout, typography, or theme tokens. Those are not blocks. You will need separate conventions for utility classes and CSS custom properties. The spec also does not address performance: BEM class names are longer than short nested selectors, but as noted, compression closes most of the gap. What the spec does give you is a complete, testable rule set that any developer can apply without asking a senior for an opinion. That is why it survived a decade and a half.

Dead CSS and Rename Paralysis: The Maintenance Dividend

Dead CSS is the silent tax on unscoped selectors. A selector like .widget .button sits in the stylesheet, and nobody knows if the .widget still exists in the markup. The selector reach is unknown because the class name .button is generic and could match anywhere. BEM removes the ambiguity: .widget__button only matches a button that is an element of a widget block. Grep for the class name in the markup, and if it is absent, delete the rule. That is a mechanical operation, not a judgment call.

Rename paralysis follows the same logic. In a global namespace, renaming .title to .subtitle requires checking every file that uses .title, and you cannot trust your search because .title might be used as a standalone class on a page that has nothing to do with your component. With BEM, .card__title is unique to the card block. Renaming it to .card__heading touches only the card component’s files. The block name is the namespace, and the namespace is the boundary of the rename.

The Cost of Not Doing It

If you skip BEM and rely on nesting, you are signing up for the specificity war on every new feature. Someone will write #main .product-card .content .title to override your .product-card .title, and the cascade will no longer be readable. The fix is not to add more specificity; it is to flatten the selectors. BEM is the cheapest way to flatten because it does not require a build step, a browser upgrade, or a framework change. It is a text-level discipline that works with any tooling.

CSS Nesting and BEM: A Caution

Native CSS nesting shipped in all engines in 2023, using the & token. You can write .card { & .title { color: red; } } and the browser compiles it to .card .title. That is convenient, but it reintroduces the exact specificity problem BEM avoids: .card .title is (0,2,0). Nest three levels and you get (0,3,0), right back in the war.

The safe pattern is to use nesting only for pseudo-classes and modifiers on the same element: .card__title { &:hover { color: blue; } } compiles to .card__title:hover, which is (0,2,0) because of the pseudo-class. That is fine; it is a state, not an escalation. What you must not do is nest .card__title inside .card, because that creates a descendant selector. BEM’s flat class names and CSS nesting are compatible only if you never use & to create descendant combinations.

/* Safe: nesting for pseudo-class, flat specificity plus state */
.card__title {
  color: #333;
  &:hover {
    color: #0066cc;
  }
}

/* Unsafe: nesting creates descendant selector, specificity (0,2,0) */
.card {
  & .card__title {
    color: #333;
  }
}

The first block is BEM-compatible. The second block is not. The browser will happily parse both, but the second one rebuilds the specificity pile you just flattened.

FAQ: BEM Methodology Questions That Come Up

Is BEM a CSS specification?

No. BEM is a naming convention defined by the Yandex BEM methodology specification at bem.info. It is not part of any W3C CSS specification and has no browser engine support because it is a text-level rule, not a browser feature.

Does BEM work with CSS modules or scoped styles?

Yes, but it is redundant. CSS modules generate unique class names per component, which gives you containment. BEM gives you containment through naming. Using both means every class has a BEM name and a hashed suffix, verbose but harmless. The choice is about team discipline, not technical capability.

What is the fallback if I cannot use @scope?

BEM is the fallback. @scope requires a browser from 2023 or later; check caniuse for current support data. BEM works in every browser that has ever shipped CSS, because it is just class names. There is no @supports guard for BEM because there is nothing to test.

Can I use BEM with utility classes like Tailwind?

Yes. BEM names the component structure; utility classes apply single-purpose styles. The risk is that a utility class like .text-red-500 has specificity (0,1,0) and can override a BEM class if the utility appears later in the source. This is a source order problem, not a BEM problem. Put utilities in a later @layer to make them win intentionally.

What happens if I forget the base class and use only a modifier?

The element loses its base styles. If you write .card__title–large without .card__title, the font-size from the modifier applies, but the base colour and margin do not, because the base rule’s selector does not match. The spec requires both classes in the markup and both rules in the CSS.

Does BEM slow down my page because the class names are long?

Longer class names add bytes, but gzip and brotli compress repeated strings well. The difference between .card__title and .card .title is a few bytes per occurrence. The maintenance savings from dead-CSS removal and no specificity debugging outweigh the payload cost.

How do I migrate an existing codebase to BEM without breaking everything?

Do not migrate in one pass. Start with new components written in BEM. For existing components, isolate them in a @layer or a @scope so they cannot leak. When you touch a component for a bug fix or a feature, rename its classes to BEM then. The migration is incremental and reversible, which is the opposite of a big-bang rewrite.

Who Should Adopt BEM and Who Should Not

BEM suits the team that writes CSS directly, without a component framework that generates scoped styles, and that needs a convention everyone can apply without debate. It suits the developer who has lived through a specificity war and wants the cascade to be boring. It suits the maintainer of a long-lived stylesheet where dead CSS has accumulated because nobody dared delete a nested selector.

BEM does not suit the team already on CSS modules or a framework that scopes styles per component file, because the framework already provides containment. It does not suit the developer who prefers utility-first CSS and composes styles from single-purpose classes, because BEM’s block-element structure fights that workflow. It does not suit the project that has committed to @scope and browser-native containment, because the naming convention is redundant overhead. The destination is flat specificity; BEM is one route, @scope is another, and you should pick the one your browser support and team habits can sustain.