In BEM, a modifier is written as a second class on the node (`class="btn btn--primary"`) rather than replacing the base class. Why, and what does that imply about how the two rules interact?

## What a modifier rule is allowed to contain In BEM a modifier expresses a *difference*, not a whole component. The base block rule holds every declaration shared by all variants; the modifier holds only what changes: ```css .btn { display: inline-flex; padding: 0.5rem 1rem; border: 1px solid transparent; border-radius: 4px; background: #eee; color: #222; } .btn--primary { background: #0057d8; color: #fff; } ``` Given that split, a node carrying only `btn--primary` would render as blue text-coloured nothing: no padding, no border radius, no inline-flex. The base class is not decoration, it is the component. That is the whole reason both classes ride together: ```html <button class="btn btn--primary">Save</button> ``` The alternative design — a self-contained `.btn-primary` that repeats every shared declaration — is what BEM is rejecting. It duplicates the component for each variant, so a change to the padding has to be made in every variant rule, and one of them will be missed. ## The specificity consequence `.btn` and `.btn--primary` are both single class selectors: identical specificity. Nothing in the naming makes the modifier stronger. When two rules of equal specificity in the same origin and layer both apply, the cascade falls through to **order of appearance**, and the later rule wins. So the modifier only overrides the base because it is written after it. This is a real ordering constraint, not a theoretical one. Author each block's modifiers immediately after that block, and never let a base rule be re-declared further down the sheet — a late `.btn { background: #eee; }` will silently defeat every modifier above it. ## The mistake that follows: attribute order Engineers frequently believe `class="btn--primary btn"` behaves differently from `class="btn btn--primary"`. It does not. The order of names inside the `class` attribute has no meaning to the cascade at all; it is an unordered set of tokens. Only the order of the *rules in the stylesheet* matters. The same applies when two modifiers collide: ```css .btn--primary { background: #0057d8; } .btn--danger { background: #c92a2a; } ``` ```html <button class="btn btn--primary btn--danger">Delete</button> ``` The button is red — not because `btn--danger` is second in the markup, but because its rule is second in the stylesheet. Reverse the two rules and the same markup turns blue. That fragility is a design signal: two modifiers that set the same property are mutually exclusive states and should be modelled as one modifier with different values (in the original Yandex syntax, a key/value modifier like `btn_theme_danger`) or simply never applied together. ## Why teams reach for `.btn.btn--primary`, and what it costs When a modifier appears not to work, the quick fix is to double the class: ```css .btn.btn--primary { background: #0057d8; } /* two classes, wins regardless of order */ ``` This genuinely works — two class selectors outweigh one — and it removes the ordering dependency. The cost is that it abandons the flat-specificity property that made BEM predictable in the first place. Every later rule that needs to override this one must now also reach two classes, and the next person will double again to win. If a modifier is losing, the honest diagnosis is almost always source order or a stray descendant selector elsewhere, and fixing that is cheaper than escalating. ## Modifiers on elements The same rules apply one level down. An element modifier is `block__element--modifier`, applied beside the element class: ```html <h2 class="card__title card__title--truncated">…</h2> ``` Again the modifier holds only the delta — the overflow and ellipsis declarations — and the element class holds the shared typography. ## Boolean versus key/value The two-dashes style treats modifiers as booleans: present or absent. The original Yandex syntax also supports key/value pairs, where a name encodes a property and its value. Key/value shines exactly where boolean modifiers get dangerous — mutually exclusive variants such as theme or size, where only one value can be true at a time. Whichever spelling you adopt, pick one for the codebase: a reader cannot parse a name whose delimiters mean different things in different files.