BEM Methodology

BEM stands for Block, Element, Modifier. It is a component-based approach to web development that was pioneered by Yandex in 2005 and later open-sourced. The core idea is simple: instead of inventing arbitrary class names, you always follow the same pattern — and that pattern itself communicates the structural role of every class in your stylesheet.

Traditional CSS quickly descends into specificity conflicts. You start with .button, then need .header .button, then .header .nav .button.is-primary. Specificity climbs, selectors couple, and changing one rule breaks three others. BEM sidesteps the entire problem by keeping every selector flat: one class, zero nesting, zero specificity battles.

The methodology is purely about naming. It works with plain CSS, Sass, PostCSS, or any other tool. It requires no build step and no runtime. The only cost is the discipline of following the convention consistently.

The three concepts map directly to a three-tier hierarchy: a page is composed of Blocks, each Block is composed of Elements, and both Blocks and Elements can carry Modifiers to express variants or states.

A key rule: Elements exist only inside their parent Block. You should never have an Element without a Block, and you should never chain Elements (card__body__title is wrong — use card__title instead, even if the title lives inside card__body in the HTML).

The BEM naming formula is straightforward. Words inside a single part are separated by a single hyphen. The two underscores mark the Block → Element boundary; the two hyphens mark the modifier.

BEM works across any scale — from a simple button to a complex navigation. The patterns below cover the most common scenarios you will encounter.

The most frequent mistake is chaining elements: card__body__title seems logical in HTML structure, but it defeats the purpose of BEM. If you later move the title out of card__body, the class name becomes a lie. Always name elements relative to their Block, regardless of DOM depth.

The second common error is applying only the Modifier without the base Block or Element class. A card--featured class on its own does nothing — the Modifier class always accompanies the base class (class="card card--featured"), because the Modifier only overrides specific properties while relying on the Block for its defaults.

At first, BEM's double-underscore and double-hyphen syntax looks verbose. On a single-page prototype, it is. But CSS grows. A stylesheet that starts at two hundred lines reaches two thousand before a team notices, and at that point the cost of not having a convention becomes very visible: cascade surprises, dead rules no one dares delete, and specificity overrides stacked three levels deep.

BEM makes three guarantees that compound over time. First, flat specificity: every rule carries weight 0-1-0, so overriding is always predictable. Second, self-documenting markup: reading an HTML file tells you the component boundaries and variants without opening a CSS file. Third, safe deletion: searching for .card__title finds every reference in one grep — unlike .title, which could mean anything.

BEM is not the only CSS architecture — SMACSS, ITCSS, Atomic CSS, and utility-first approaches like Tailwind solve the same problems with different trade-offs. But BEM remains the most widely adopted naming convention for component-based CSS, and understanding it is foundational to reading and contributing to most large design systems.