BEM and Naming Conventions

## Why a naming convention exists at all CSS has exactly one global namespace. A selector written anywhere matches anywhere in the document, so two engineers who both write `.title` in two different stylesheets silently fight over the same elements. BEM — Block, Element, Modifier, originally from Yandex — answers that by putting the scope into the name itself: the class *is* the namespace. The whole methodology is a grammar for class names plus one structural rule (one class per rule). ## Block A block is a standalone, meaningful chunk of interface that would still make sense if you moved it somewhere else on the page: `.card`, `.menu`, `.site-search`, `.pagination`. Two naming disciplines matter here. First, name it for **what it is**, never for how it looks or where it sits — `.card`, not `.blue-box` and not `.sidebar-thing`, because the colour will change and the sidebar will move. Second, a block should not set its own external geometry (outer `margin`, `position`, a `width` that only fits one slot), because that hard-codes one context into a component meant to be reusable. ## Element An element is a part of a block that has no standalone meaning — a card's title, a menu's item, a form's submit row. It is written with the block name, two underscores, then the element name: ```css .card { } .card__media { } .card__title { } ``` Two things surprise newcomers. The element name is **flat**: it names ownership, not DOM depth, so a heading nested three levels inside the card is still `.card__title`, not a path through its ancestors. And the class is used as a **single class selector** — you write `.card__title { }`, not `.card .card__title { }`; the prefix has already done the scoping work that a descendant selector would otherwise do. ## Modifier A modifier is a flag that changes appearance, state or behaviour of the block or element it hangs off: `.card--featured`, `.button--ghost`, `.card__title--truncated`. It is applied as an extra class next to the base one: ```html <article class="card card--featured"> <h2 class="card__title">Release notes</h2> </article> ``` The modifier rule carries only the *difference* from the base, which is why both classes must be present. ## The two spellings The original Yandex syntax marks modifiers with a single underscore and optionally a value: `block__elem_mod_val`. The variant most teams use today — popularised by the getbem.com write-up — is the "two dashes" style: `block__elem--mod`. Both are legitimate BEM; what is not legitimate is mixing them in one codebase, because the delimiters are the only thing telling a reader which part of the name is which. ## What the grammar actually buys - **Readability from the markup alone.** Seeing `class="card__footer"` in a template tells you which stylesheet component owns it, without grepping. - **Flat specificity by construction.** Every selector is one class, so they all weigh the same and conflicts resolve by source order rather than by who nested deeper. - **Safe deletion.** Removing a component means removing one name prefix; nothing else in the sheet claims those names. - **Visible misuse.** A `card__title` appearing outside a `card` is an obvious defect to a reviewer, which a generic `.title` never would be. ## Mixes: putting a block inside another block Because blocks must not own their outer positioning, BEM uses a **mix** — two entities on one DOM node: ```html <ul class="feed"> <li class="feed__item"> <article class="card">…</article> </li> </ul> ``` or, collapsing the node, `<article class="card feed__item">`. The `card` class supplies the component; the `feed__item` class supplies the parent's layout slot. The card stays context-free and reusable. ## The mistakes reviewers look for Chaining element names (`card__body__title`); naming blocks after appearance; applying a modifier without its base class; and re-introducing descendant selectors such as `.card .card__title`, which throws away the flat specificity the naming already guaranteed.