The Cascade, Inheritance and Scope

1. The cascade as a sort

Pick any element and any property, say the color of one link. The browser's own style sheet sets it. A reset may set it. A base rule for links sets it, a component rule sets it, a utility sets it, and a style attribute might set it too. The CSS specifications call every one of those a declared value. The element can only have one color, so the browser needs a rule for choosing.

"The last one written wins" is true, but only at the very end. The cascade is a multi-stage sort. Each stage compares the competing declarations on one criterion. If one declaration comes out ahead, the sort stops and that declaration wins. If several tie, only the tied ones move on to the next stage. The winner is the cascaded value.

Two things about the funnel matter more than the details. First, the order is fixed: a stage lower down can never overturn a decision made higher up. A selector with enormous specificity still loses to a plain one in a later layer, because layers are compared first. Second, the bottom four stages are the ones you control by how you write a style sheet, and they are the subject of most of this page.

Origin and importance

CSS Basics introduced the three origins (user-agent, user and author) and the way !important reverses their order. The full first stage has two more entries. While a CSS animation runs, its values sit just below every important declaration and above all normal ones. While a transition runs, its values beat everything, because a transition is meant to move smoothly from the old value to the new one whatever else is going on.

Folding in the later stages that matter most to authors, the style attribute and layers, gives the complete order. It reads strongest first:

Within any one row, specificity, scope proximity and order of appearance break the remaining ties. Notice where the style sheet you write spends its life: almost everything is in rows 10 to 12. Those rows tie at the first stage, and that is why layers, specificity and order do the real work.

The stages after origin

• Context separates a web component's shadow tree from the page around it. For normal declarations the outer page wins, so a page can restyle a component it uses; for important ones the component's own styles win, so it can protect what it must.
• Element-attached styles are the declarations in a style attribute. They have no selector, so they skip specificity entirely and beat every rule of the same origin and importance. "Inline styles have the highest specificity" is a common shorthand for this, but the real mechanism is a stage of its own.
• Layers, specificity and scope proximity each get a section below or on the selectors page.
• Order of appearance is the final word: when everything else ties, the declaration that comes last wins, counting through linked sheets, @imports and style elements in the order the document includes them.

2. !important, and why layers replace it

Older CSS teaching, this course's earlier slides included, offered !important as the way to say "this rule should never be overridden":

The keyword attaches to a single declaration, here only the color, and moves it into a stronger bucket at the first stage of the cascade. That sounds like a clean tool. In practice it starts an arms race. A third-party sheet uses !important to win, so the site's own sheet uses it to win back, so the next fix needs it too. Each use removes an escape route, and specificity battles reappear inside the important bucket. A style sheet full of !important is one in which nobody can predict what wins.

Users always win

The keyword also cannot do what its name promises. As the origins table shows, importance reverses the order of origins: a user's !important beats an author's !important. That is deliberate policy. A reader with low vision who forces larger text or higher contrast, through browser settings, an extension such as Stylus, or a forced-colors mode, must be able to override any page. Try it with any user style extension: change a site's fonts, hide its banners, enlarge its text. No author declaration, important or not, can stop it. The web is a medium where the reader has a say, and !important was built partly to guarantee that.

What authors were really asking for

Most author uses of !important were never about one declaration. They were about a group of rules: "the site's own styles should beat the framework's", or "utilities should beat components". Specificity cannot say that, and source order is fragile once files load from several places. @layer says it directly. A rule in a later layer beats any rule in an earlier one, however specific, with no keyword at all:

The utility's selector has a specificity of zero and the component's has four type selectors, yet the utility wins, because utilities was declared after components. The house style in this section never uses !important. A short list of deliberate guards remains defensible, such as [hidden] { display: none !important; } to keep the hidden attribute working when other rules set display, but those are rare, commented decisions rather than a way to win arguments.

3. @layer

Cascade layers give a style sheet named tiers inside the author origin. They have been Baseline since 2022 and are now widely available, so they are safe to use everywhere.

Three ways to write a layer

The statement form declares names and their order without any rules. Write it once, at the top of the first style sheet:

The block form puts rules into a layer. Blocks can appear in any order and in any file; each one joins the layer of its name, and the layer keeps the position the statement gave it. Repeating a block name adds to the same layer:

The import form, shown in CSS Basics, places an entire file into a layer: @import url("vendor.css") layer(vendor);. This is the cleanest way to bring in a framework or a third-party widget's CSS without letting it outrank your own.

A few more details are worth knowing. A layer's position is fixed the first time its name appears, which is why the statement belongs at the very top. A name first seen later is added after all the existing layers. A @layer { … } block with no name creates an anonymous layer that nothing else can add to. Layers can nest, as in @layer components { @layer card { … } }, and the inner layer can then be referred to as components.card.

Where layers sit

Layers are compared at stage 4 of the cascade, after origin and importance, after context and after the style attribute, and before specificity. Three rules follow from that position:

• The first layer declared is the weakest; the last is the strongest. It matches the cascade's general habit that later wins.
• Unlayered styles beat every layer. Any rule not inside a layer acts as if it were in one final, implicit layer after all the named ones.
• A style attribute beats every layer as well, because element-attached styles are compared one stage earlier.

The second rule surprises people who expect layers to add priority. It is the safe default: an existing style sheet with no layers keeps winning over any library you move into a layer, so adopting layers can start with a single @import … layer(vendor) and nothing else changes.

Importance reverses the layers

The cascade has one consistent rule for !important: it reverses ordering. It reverses the origins, and it reverses the layers too. For important declarations, an earlier layer beats a later one, and unlayered important declarations are the weakest important declarations of all.

The reversal has a practical consequence. Put a framework in a vendor layer and its normal rules lose to all of yours. Its !important declarations, though, still beat your normal ones, and they also beat any !important you write in a later layer or unlayered. To outrank them with importance you would need a layer declared before vendor. Usually the better answer is not to fight at all: report the problem upstream, or replace the rule.

Backing out of a layer

The global keyword revert-layer rolls a property back to whatever the cascade would have produced without the current layer: the value from earlier layers, or from the browser if no layer set one. A component layer can use it to defer to the base styles for one property without repeating them. The properties page covers it alongside the other global keywords.

4. @scope

Sometimes a group of rules should apply only inside one part of the page, and stop at a boundary inside that part. Article typography should not leak into an embedded widget. A card's styles should not reach into a card nested inside it. Before @scope, the choices were long descendant selectors, naming conventions such as BEM, or build tools that rewrote class names. Each one costs something: brittle selectors, verbose markup, or a dependency on the build.

@scope is the language's own answer. It shipped in Chrome in 2023 and Safari in 2024, and reached Baseline (newly available) once Firefox, the last of the major engines, added it. For anything a page cannot live without, treat it as an enhancement for now.

The scope root, and the limit

The prelude names a scope root. Rules inside match only the root and its descendants:

The optional to (…) clause names a scope limit, a lower boundary. Elements matching the limit, and everything inside them, are outside the scope. The styled region is shaped like a ring with a hole in it, which is why this pattern is often called donut scope. Inside the block, :scope matches the root itself.

A style element can also use @scope with no prelude at all. The scope root is then the style element's parent, which gives HTML a working form of the long-abandoned <style scoped> idea:

Scope adds structure, not specificity

The root selector in the prelude does not count toward the specificity of the rules inside. A bare p inside @scope (main > article) matches like main > article p but keeps the specificity of a single type selector, (0, 0, 1). Writing :scope p adds a pseudo-class and gives (0, 1, 1). That is the point of the feature: it constrains where rules match without making them harder to override.

Proximity

@scope also added a stage to the cascade. When two scoped rules of equal specificity disagree, the one whose scope root is nearer to the element, counting steps up the tree, wins. Without that stage, nested themes would fail: in a light section placed inside a dark page, both themes' link rules would tie on specificity, and source order would pick the same theme everywhere regardless of nesting.

A link inside a light section, inside a dark page, takes the light color, because the light root is the nearer ancestor. Flip the nesting and the dark color wins, whatever order the rules are written in.

What scope does not isolate

@scope limits which elements its selectors can match. It does not stop inheritance. If a scoped rule sets color on a p, every element inside that p inherits the color, including elements inside a scope limit. Stopping an inherited value at a boundary takes an explicit declaration on the boundary element, such as color: initial or a fresh value. Full style isolation, where nothing outside gets in, is what the shadow DOM of web components provides.

5. Nesting

CSS Basics introduced nesting as a way to make a style sheet follow the shape of its HTML. Native nesting has been Baseline since 2023 and is now widely available, so the feature that once required Sass or Less now works without a build step.

Nesting is notation

A nested rule produces exactly the selectors a flat style sheet would have written out. Nothing about which elements match changes; only the text is organized differently. This rule:

means the same as these flat rules:

The rules for & are short:

• & stands for the parent selector, and can appear anywhere in the nested selector: &:hover, & + &, aside &.
• With no &, a nested selector is a descendant of the parent: a inside article means article a, and > h2 means article > h2.
• A pseudo-class attached to the parent needs the &: &:hover is the article being hovered, while :hover on its own means any hovered descendant.
• Conditional at-rules such as @media, @container and @supports nest too, and declarations directly inside them apply to the parent selector. Keeping a component's adaptations next to its base styles is one of nesting's best uses.

Not Sass

Native nesting joins selectors, not strings. Sass lets &__title glue a suffix onto a class name, a habit of BEM-style CSS:

In the browser, &__title is not a valid selector, so the rule is dropped. The structure-first answer does not need the trick: the title of a card is its heading, and article { > h2 { … } } selects it.

The specificity of &

& carries the specificity of its parent as if the parent were wrapped in :is(). When the parent is a list, that means the highest specificity in the list, applied to every match:

Here even a plain article on hover is matched at (1, 1, 0), the id's specificity plus the pseudo-class, and anything later that tries to override it must outweigh an id. Wrapping the list in :where() sets the parent's contribution to zero, so the nested rule counts only its own selector:

How deep to nest

Nest when the inner rule cannot meaningfully exist without the outer one: states such as &:hover and &[aria-expanded="true"], direct parts such as > h2, and media or container adaptations. Stop at two levels. By the third, a reader has to unroll the selector in their head to know what it matches, and its specificity and its coupling to the markup have grown just as if it were written out longhand. If a nested rule could stand alone, such as buttons that look the same everywhere, it belongs at the top level.

6. Inheritance, and the computed-value pipeline

The cascade picks a winner when declarations compete. Most of the time, for most properties, nothing competes at all: no rule anywhere sets the color of a particular em. The value comes from inheritance, and this is where the document tree from the selectors page pays off. A property set on an ancestor flows down to its descendants unless something stops it.

Which properties inherit

Each property's definition says whether it inherits. The pattern follows common sense about documents:

Typography is something you set on a container and expect everything inside to share; set the font once on body and the whole page follows. Boxes are per element: if a section's padding were inherited, every paragraph inside it would be padded again. Custom properties inherit so that a token set once on :root is visible everywhere. A typed custom property registered with @property can opt out with inherits: false, as the values page shows.

When a property has no cascaded value, the browser fills one in, a step the specification calls defaulting. An inherited property takes the parent's value. A non-inherited property takes its initial value, the default written into its definition, such as transparent for background-color. Any property can be pushed the other way with the global keywords: inherit forces inheritance even for a box property, and initial blocks it. A common use is button { font: inherit; }, which lets form controls share the page's typography instead of the browser's defaults.

The computed-value pipeline

The cascade's winner is not yet a number the screen can use. 1.25em depends on the parent's font size; 50% depends on the size of the container; var(--space) is only a reference. Each property on each element passes through a pipeline of values, each one resolved a little further than the last.

The pipeline explains a few behaviors that otherwise look arbitrary. DevTools' Computed panel shows the computed value, or for some properties the used value, which is why it can report pixels for a size you wrote in rem. getComputedStyle() in JavaScript returns the same thing, for the same reason.

Children inherit the computed value

Inheritance passes down the parent's computed value, not the text that was written. That matters most for line-height:

In the article, 1.5em computes to an absolute length, 24 pixels at the default font size, and that length is what its h2 inherits: a 32-pixel heading squeezed into 24-pixel lines. In the aside, the unitless 1.5 computes to the number itself, so each descendant multiplies its own font size by 1.5 and the heading gets 48-pixel lines. Write line-height as a plain number. The same reasoning explains currentColor, which stays live: it always means the element's own color, whatever that turns out to be.

7. Applied: from class-itis to structure-first styling

The cascade, layers, scope and inheritance all point toward the same way of writing CSS. The clearest way to see it is to start with the opposite.

Presentational class-itis

The markup below starts out well, with a real h1. Then it catches what this course calls presentational class-itis: class names that describe a look rather than a meaning.

The result looks reasonable, and that is the trap. The presentation has moved back into the HTML; the separation of concerns that CSS Basics started with is gone. Redesigning the headings now means editing markup on every page that uses them. The name underline becomes a lie the day the design drops underlines. style-8 says nothing to the next developer, and the fixed pixel sizes and the physical margin ignore the reader's font settings and the writing direction. It is <font> tags again, with extra steps.

Three better bindings

The course's original slides offer three alternatives, and each is better than class-itis:

1. Style the element itself when every h1 should look this way: h1 { … }.
2. Use a meaningful class when only some h1 elements should: <h1 class="intro-heading">. The name says what the heading is, not how it looks.
3. Rely on context: the heading of the page's introduction is already identifiable by where it sits in the structure.

The slides then add the crucial caveat: whichever selector you choose, values such as 48px and #c00 are magic numbers mixed into the rules. Treat them the way you would in any other code: name them once as constants. In CSS those constants are custom properties.

The structure-first version

The markup says only what things are:

And the style sheet binds the look to that structure, with every value named and every rule in a layer:

Every h1 gets the display font and a fluid size that respects the reader's default text size. The page heading, identified by its place in the structure, adds the accent color and the underline. Changing the design means changing the style sheet, once. If a later design needs a heading variant that the structure cannot express, a meaningful hook is still welcome, written so it adds no weight: h1:where(.intro-heading) keeps the specificity of a bare h1.

An order for the whole style sheet

The slides also proposed an order for a style sheet: variable definitions, a reset, utilities, broad element rules, elements in context, class overrides, id rules, and finally hacks. Before layers, that order could only be kept by discipline and source order. Layers turn it into something the browser enforces:

The slides' warning still holds: follow an order like this with sound markup and things work very well; skip it and you may find yourself with a 2,500-line style sheet, fighting for your layout's life. The difference now is that the cascade itself can carry the architecture, instead of every developer's memory.

8. Summary