You maintain a shared CSS component library used by other teams. How do you author its default rules so a consumer's own single-class rule can override them, without them resorting to `!important` or copying your selector structure?

## The problem being solved A library author has an asymmetry problem. You want your defaults to apply out of the box, but you do not want them to be *hard to beat*, because everything consumers do to beat them becomes weight in their codebase that they can never remove. If your dialog is styled as `.dialog .dialog__header h2`, then every consumer who wants a different heading colour writes something heavier, and your library is the reason their stylesheet is on the escalation ladder. So the design target is: defaults that apply, but lose to anything intentional. ## Mechanism one — zero-weight selectors `:where()` matches its argument but contributes nothing to specificity: ```css /* Applies, but any authored rule beats it */ :where(.dialog) { padding: 1rem; border-radius: 0; } :where(.dialog) :where(h2) { margin-block: 0; } ``` A consumer's `.dialog { padding: 2rem; }` now wins regardless of where it loads, because the library's rule has weight zero and any real selector beats zero. This is precise, works per-rule, and needs nothing from the consumer's build. It has been available across the major browsers since early 2021. The cost is that it applies to *everything* in the parentheses, so you must be deliberate. A rule you genuinely do not want overridden by accident — an internal structural rule that makes the component function — should keep normal weight. ## Mechanism two — cascade layers ```css @layer library { .dialog { padding: 1rem; } } ``` For normal declarations, unlayered author styles take precedence over any layered ones, whatever their weight. So a consumer who writes plain CSS beats your layered defaults without doing anything at all; a consumer who uses layers themselves can declare an order that puts theirs after yours. Layers landed in Chrome 99, Firefox 97 and Safari 15.4, all in 2022. The cost is coordination. Layer priority depends on the order the layer *names* are first encountered, which depends on how your stylesheet is included in the consumer's bundle. That makes the layer name and its expected position part of your public API — document it, and treat renaming it as a breaking change. ## Which to use They compose, and the honest answer is both. Layers handle the coarse question — the whole library sits below consumer code. `:where()` handles the fine one — specific rules, especially ones that touch elements the consumer's own selectors will naturally target, drop to zero so no ordering assumption is needed at all. One caution: layers do not neutralise weight *within* a layer. If your library contains both `.dialog` and `#app .dialog`, consumers are shielded from your library's weight relative to their code but your own internal rules still fight each other. Flat authoring inside the library is still required. ## What not to do - **Do not ship `!important` defaults.** It forces every consumer onto importance permanently. - **Do not rely on load order alone.** "Just import our stylesheet first" is not enforceable; bundlers, code splitting and lazy-loaded chunks all reorder things. Weight and layers survive reordering, comments do not. - **Do not encode your DOM in selectors.** `.dialog > .dialog__body > p` couples consumers to internal structure and hands them a heavy rule to fight. - **Do not expose an override surface only through selector escalation.** Where a value is genuinely meant to be configured, a custom property is a better contract than a selector, because the consumer sets a value instead of winning a fight. ## The contract framing The deeper point is that override-ability is a public interface. A library that ships at zero weight has decided that consumers own the final word; a library that ships heavy rules has decided the opposite, usually by accident. State the decision explicitly in the docs — which layer the styles land in, which rules are zero-weight and therefore freely overridable, and which are structural and expected to stay. Consumers can then plan their own architecture around it instead of discovering the answer through a failed override.