Managing Specificity with Cascade Layers

The Old Way of Overriding a Library's Styles

/* A third-party library's button style */
.library .btn { padding: 8px 16px; }

/* Forced into an overly specific selector just to win */
.app-container .toolbar .btn { padding: 12px 24px; }

Before cascade layers, overriding a style from an external library often meant writing an unnecessarily specific selector, or reaching for !important - both of which make a stylesheet harder to reason about and even harder to override again later.

How Layers Remove the Need for This

@layer library, app;

@layer library {
  .btn { padding: 8px 16px; }
}

@layer app {
  .btn { padding: 12px 24px; } /* wins - layer order, not specificity */
}

Because app is declared after library, any rule in app beats any rule in library targeting the same element - even though both selectors here have identical specificity. No selector escalation or !important is required.

Wrapping an Imported Stylesheet in a Layer

@import url("some-library.css") layer(library);

An entire external stylesheet can be imported directly into a named layer, instantly guaranteeing that every rule inside it will lose to anything in a later-declared layer - a clean way to "tame" a third-party stylesheet's specificity in one line.

A Practical Layer Ordering Convention

@layer reset, third-party, base, components, utilities;

A common convention places resets first, then third-party/vendor CSS, then a project's own base styles, then components, with utility classes last so they can always override a component's default styling when needed - directly answering the question "why isn't my override working?" that specificity alone often left unclear.