What is BEM methodology (block element modifier)

BEM (Block Element Modifier) - a CSS class naming convention where every class follows a block__element--modifier pattern to prevent style collisions across a codebase.

#Theory

#TL;DR

• Block = standalone UI piece (button). Element = part that only lives inside that block (button__icon). Modifier = a variation or state (button--primary).
• Think LEGO: block is the base piece, element attaches only to that piece, modifier swaps its look.
• Main win: .menu__item--active stays scoped to menus and never clashes with .button--active.
• Use BEM on teams with 5+ devs or CSS over 10k lines. Skip it for tiny prototypes or CSS-in-JS projects.

#Quick example

The class name tells you the full relationship. button__icon--large is a large icon inside a button. Nothing else, nothing more.

#Key difference

A flat class like .active is global. Merge three feature branches and you get three different .active rules fighting each other. That is the most common CSS conflict I have seen in team codebases. BEM namespaces everything: .card--active, .menu__item--active, .button--active are three separate selectors that cannot touch each other.

#When to use

• Teams with 5+ developers or CSS over 10k lines: BEM naming prevents merge conflicts and unintended overwrites.
• Reusable component libraries: elements tie to their block, so there is no semantic drift over time.
• Vanilla CSS without build tools: BEM gives you scoping without PostCSS or Webpack.
• CSS-in-JS (Styled Components, Emotion): skip BEM, the library hashes class names automatically.
• Tailwind CSS: skip BEM, utility classes replace naming conventions entirely.
• Small solo project under 5 files: flat classes are faster to write and BEM overhead is not worth it.

#Comparison

| Aspect | BEM | Flat CSS (.btn.active) | CSS Modules | |---|---|---| ---| | Naming | block__element--mod | .class, .state | Button_module__root | | Scalability | High (namespaced) | Low (global collisions) | High (hashed at build time) | | Team size | 5+ devs | Solo or small | Any size | | Debugging | DevTools shows hierarchy | Hunt globals | Safe but obfuscated names | | Best for | Vanilla or team CSS | Prototypes | React/Vue components |

#How browsers handle BEM

No runtime magic. Browsers parse BEM classes as standard CSS selectors. .button__element has specificity (0,1,0), same weight as any single class. That's it. Structure lives in the name, not in nesting or shadow DOM. Write flat selectors in CSS, never .button .button__icon {}.

#Common mistakes

Nesting selectors in CSS:

Chaining too many modifiers on one class:

Deep element nesting:

Expecting a block modifier to suppress an element modifier:

#Real-world usage

• Yandex (where BEM was created) applies it in codebases over 1 million lines: search__input--focused.
• BBC News uses it for modular templates: article__headline--breaking.
• Shopify themes follow BEM naming: product-form__input--error.
• Google AMP uses it consistently: amp-form__submit-button--disabled.

#Follow-up questions

Q: Explain block, element, and modifier with an e-commerce example.
A: Block is cart. Element is cart__item (one row in the cart). Modifier is cart__item--out-of-stock (strikethrough price, greyed out). The cart can appear anywhere on the page. The item only makes sense inside the cart.

Q: How does BEM specificity compare to plain classes?
A: .block__element has specificity (0,1,0), same as .element. BEM itself does not boost selector weight. Protection comes from the unique name. No !important needed.

Q: Would you use BEM in a React project that already uses CSS Modules?
A: Probably not. CSS Modules hash class names at build time, so .button in one file never collides with .button in another. Adding BEM on top would add verbosity without solving a problem Modules already handles.

Q: (Senior) If a block has a modifier and one of its elements also has a modifier, does one affect the other?
A: No. .card--loading changes the block. .card__spinner--fast changes the element. They are independent selectors and the browser applies both. If you want the spinner hidden while loading, add an explicit rule: .card--loading .card__spinner { display: none; }.

#Examples

#Basic button component

Two buttons, one block, two modifiers. Neither style leaks outside .button.

#E-commerce product card

--featured on the block lets you add a border or badge without touching any element styles. --sale on __price turns the price red with a strikethrough. No selector here needs more specificity than a single class.