Real-World CSS Cascade Scenarios

Introduction

The CSS cascade becomes easier to understand when it is applied to realistic code rather than memorized as an isolated formula. Production pages combine browser defaults, design systems, framework styles, component rules, utility classes, themes, responsive conditions, inline values, animations, and user preferences. Several of those sources can propose a different value for the same property on the same element.

The browser resolves every conflict through a defined sequence. It filters declarations for relevance, compares origin and importance, considers encapsulation and cascade layers, then compares specificity, scope proximity, and source order. Inheritance and defaulting provide values after the cascade. The following scenarios show where each stage becomes decisive and why shortcuts such as "IDs always win" or "the last rule wins" are incomplete.

How to Read the Scenarios

Each scenario identifies the competing declarations, the result, and the first cascade stage that separates them. Once a stage decides the winner, later stages are irrelevant. A selector with impressive specificity cannot recover after losing to a stronger origin or layer.

Specificity is written as A-B-C: IDs; classes, attributes, and pseudo-classes; then type selectors and pseudo-elements. Combinators and the universal selector add no weight. All examples assume the same document and author origin unless another context is stated.

The Practical Cascade Sequence

Scenario 1: Type Selector vs Class Selector

p { color: blue; }
.message { color: green; }

<p class="message">Welcome</p>

The class selector has specificity 0-1-0, while the type selector has 0-0-1. The message is green because all earlier cascade factors tie and the class is more specific. Source order would matter only if specificity also tied.

Scenario 2: Class Selector vs ID Selector

.message { color: green; }
#status { color: red; }

<p id="status" class="message">Success</p>

The ID selector has 1-0-0 and wins over the class's 0-1-0, so the result is red. This does not prove that IDs always win; it proves they win specificity when preceding cascade stages are equal.

Scenario 3: Equal Specificity and Source Order

.button { background: blue; }
.button { background: green; }

Both declarations have the same origin, importance, layer, context, and specificity. The later rule therefore wins, producing green. This is the precise situation described by "last rule wins."

Scenario 4: Two Classes on One Element

.btn { background: blue; }
.danger { background: red; }

<button class="btn danger">Delete</button>

Each selector has specificity 0-1-0. Because .danger appears later, the button is red. The order of class names inside the HTML attribute does not decide the result; stylesheet source order does.

Scenario 5: Compound Selector

.danger { background: red; }
.btn.danger { background: darkred; }

The compound selector contains two classes and has 0-2-0, so it beats .danger at 0-1-0. Dark red wins even if the simpler rule is moved later. Use compound state selectors intentionally because they raise future override cost.

Scenario 6: Descendant Selector

.text { color: gray; }
.card .text { color: blue; }

The descendant selector contains two classes and wins through specificity. The space combinator adds no weight; the additional .card does. If every card text should be blue, this may be appropriate. If text is a reusable component, token-based variation may be easier to maintain.

Scenario 7: Normal Inline Style vs Stylesheet

<p class="note" style="color: red;">Important</p>

.note { color: blue; }

The normal inline declaration wins over the normal author style rule, so the note is red. DevTools lists the source as element.style. A normal selector cannot beat it merely by adding classes or an ID.

Scenario 8: Important Rule vs Normal Inline Style

<p style="color: red;">Welcome</p>

p { color: blue !important; }

The author important rule wins before inline specificity becomes relevant, so the paragraph is blue. Importance is a separate cascade stage rather than a numeric increase to selector weight.

Scenario 9: Two Important Rules

p { color: blue !important; }
.message { color: red !important; }

Both declarations have equal importance and origin. Assuming they are in the same layer, specificity is compared and the class wins over the type selector. An element with the message class is red.

Scenario 10: User Important vs Author Important

Suppose a site marks text gray with an author important declaration, while a user stylesheet marks text black and important for readability. The user important declaration wins because important origin order protects user needs over author styling.

This is expected accessibility behavior. Authors should not attempt to defeat user preferences with stronger selectors.

Scenario 11: External CSS Followed by Embedded CSS

<link rel="stylesheet" href="site.css">
<style>
  .title { color: green; }
</style>

If site.css contains an equal normal .title rule setting blue, the embedded declaration wins because it occurs later in source order. Embedded placement itself carries no special superiority over external placement.

Scenario 12: Embedded CSS Followed by External CSS

<style>
  .title { color: green; }
</style>
<link rel="stylesheet" href="site.css">

With an equal .title rule in the later file, the external blue declaration wins. This reversal confirms that order, not the storage method, resolves the tie.

Scenario 13: Browser Default vs Author Rule

A browser gives headings default size, weight, and margins. An author rule such as h1 { font-size: 24px; font-weight: 400; } normally overrides those user-agent declarations because normal author origin outranks normal user-agent origin.

Properties the author does not set continue to come from other matching or defaulting sources. The browser does not discard its entire heading rule.

Scenario 14: Inherited Value vs Direct Rule

.container { color: blue; }
p { color: red; }

A paragraph inside the container is red. The parent's blue is available through inheritance only when the child has no cascaded color. The parent's class specificity does not travel with the inherited value.

Scenario 15: Inheritance Without a Direct Rule

.container { color: blue; }

<div class="container">
  <p>Hello</p>
</div>

The paragraph becomes blue because color inherits and no direct declaration replaces it. DevTools shows the inherited source beneath the child's matched rules.

Scenario 16: A Non-Inherited Property

.container { border: 2px solid blue; }

The container gets a border, but its paragraph does not. border is not inherited by default. No selector conflict exists on the paragraph; it uses the property's defaulting behavior.

Scenario 17: Framework Rule and Later Custom Rule

/* framework.css */
.btn { background: gray; }

/* custom.css loaded later */
.btn { background: blue; }

The selectors tie, so the later custom declaration wins. Loading application overrides after a framework can work for simple equal-weight cases, but layers provide a clearer architecture for larger systems.

Scenario 18: Framework Has Greater Specificity

.navbar .btn { background: gray; }
.btn { background: blue; }

The framework selector has 0-2-0 and beats the later 0-1-0 rule if earlier stages tie. A deliberate matching component selector or lower framework layer can solve the ownership issue. Reaching immediately for important creates a harder future conflict.

Scenario 19: Active Media Query With Equal Specificity

.card { width: 400px; }

@media (width <= 768px) {
  .card { width: 100%; }
}

On a narrow viewport both declarations are relevant and equally specific, so the later responsive rule wins. On a wide viewport the conditional rule is excluded before the cascade compares candidates.

Scenario 20: Media Query Does Not Add Priority

#card { width: 400px; }

@media (width <= 768px) {
  .card { width: 100%; }
}

For an element with both identifiers, the active media rule still loses to the ID's specificity. A media query controls relevance, not weight. A mobile-first architecture with low-specificity base selectors prevents this trap.

Scenario 21: Hover State

.button { background: blue; }
.button:hover { background: green; }

While hovered, both selectors match. The pseudo-class raises the state selector to 0-2-0, so green wins. Without hover, only the base rule is relevant.

Scenario 22: Hover State vs ID

.button:hover { background: green; }
#submit { background: red; }

A submit button matching both remains red during hover because 1-0-0 beats 0-2-0. This is why styling reusable components through IDs can make ordinary states difficult to express.

Scenario 23: :where() Keeps Defaults Weak

:where(.card h2) { color: navy; }
.title { color: red; }

:where() and all its arguments contribute zero specificity. The title class therefore wins easily, producing red. This pattern is effective for resets and contextual defaults that should remain simple to override.

Scenario 24: :is() Can Add Unexpected Weight

:is(.card, #featured) .title { color: blue; }
.title { color: red; }

:is() takes the specificity of its strongest argument. The ID alternative gives the first selector ID-level weight even when matching through .card, so blue wins. Avoid unnecessary IDs in shared functional selector lists.

Scenario 25: :not() and :has() Follow Similar Rules

.card:not(#archived) .title { color: green; }
.card .title { color: navy; }

The ID argument inside :not() contributes to specificity, making the green rule stronger. The same argument-specificity behavior applies to :has(). These selectors can silently create heavy component rules.

Scenario 26: Shorthand Resets a Longhand

.card {
  background-image: url("image.jpg");
  background: blue;
}

The later shorthand sets all background longhands. Because it omits an image, background-image resets to none while the color becomes blue. The shorthand did not win through greater specificity; its later declaration set the same expanded longhand.

Scenario 27: Longhand After a Shorthand

.card {
  background: blue;
  background-image: url("image.jpg");
}

The later longhand replaces only the image component. The card keeps its blue background color and adds the image. Expanding shorthands in DevTools reveals this property-level cascade.

Scenario 28: Custom Property in a Component

:root { --primary-color: blue; }
.card { --primary-color: green; }
.button { background: var(--primary-color); }

A button inside the card uses green because the nearer inherited custom-property value wins on its inheritance path. The final background declaration did not change; the token it consumes changed.

Scenario 29: Invalid Custom-Property Substitution

.panel {
  --gap: wide;
  gap: var(--gap);
}

The custom property accepts arbitrary tokens, but wide is invalid for gap. Once substitution makes the winning declaration invalid at computed-value time, the browser does not revive an earlier losing gap declaration. A valid fallback or validated token fixes the problem.

Scenario 30: Important Utility Class

.card { display: block; }
.hidden { display: none !important; }

An element with both classes is hidden. Some utility systems use important deliberately so a utility guarantee survives component selectors. The convention should be documented because an important utility also affects debugging and accessibility states.

Scenario 31: Normal Cascade Layers

@layer framework, components;

@layer framework {
  .button { background: gray; }
}

@layer components {
  .button { background: blue; }
}

The component rule wins because its layer appears later in the declared order. Specificity ties, but layer precedence would be decisive even if the framework selector were stronger.

Scenario 32: Layer Order Beats an ID

@layer framework, custom;

@layer framework {
  #submit { background: gray; }
}

@layer custom {
  .button { background: blue; }
}

The normal class rule wins because the custom layer has higher normal precedence. The browser never compares the class with the ID at the specificity stage.

Scenario 33: Unlayered Normal CSS

@layer framework {
  #submit { color: red; }
}

.button { color: blue; }

Normal unlayered author declarations outrank normal author declarations inside layers. The button is blue even though the layered selector uses an ID. This makes layers useful for containing third-party CSS, but accidental unlayered rules can bypass the intended architecture.

Scenario 34: Important Layer Order Reverses

@layer foundation, components;

@layer foundation {
  .dialog { visibility: hidden !important; }
}

@layer components {
  .dialog { visibility: visible !important; }
}

The foundation declaration wins because important layer order is the reverse of normal layer order. Earlier layers protect important guardrails from later important overrides.

Scenario 35: Animation vs Normal Rule

.pulse {
  opacity: 0.4;
  animation: fade 1s infinite alternate;
}

@keyframes fade {
  to { opacity: 1; }
}

While the animation runs, its interpolated opacity outranks normal author declarations. An important declaration would outrank the animation. Selector specificity is not the deciding factor.

Scenario 36: Active Transition

A button changes from blue to red through a background transition. During interpolation, the transition value has very high precedence, even above important declarations. The new cascade winner supplies the transition target, but the intermediate painted color persists until the transition completes.

Disable transitions in DevTools when diagnosing a value that appears temporarily incorrect.

Scenario 37: Scoped Rules With Equal Specificity

@scope (.article) {
  .title { color: navy; }
}

@scope (.featured-card) {
  .title { color: teal; }
}

For a title inside a featured card inside the article, the featured-card scope may win because its scope root is closer. Scope proximity is checked after specificity and before source order.

Scenario 38: Shadow DOM Boundary

An application rule targets .price, but the price is inside a component's shadow root. The outer selector does not match the internal element, regardless of specificity. The component must expose a supported customization route such as a custom property or ::part().

This is an encapsulation and matching issue rather than an ordinary selector contest.

Scenario 39: Logical and Physical Properties

.item {
  margin-left: 2rem;
  margin-inline-start: 1rem;
}

In a left-to-right horizontal writing mode, both declarations can map to the left side and the later logical declaration controls it. In another writing mode, mapping changes. Prefer a consistent logical-property system to avoid direction-dependent conflicts.

Scenario 40: Production Bundle Reorders a Tie

Two component modules contain equal selectors, and development loads module A after B while the production optimizer emits B after A. The visible winner changes because source order changed. Inspect the delivered CSS rather than assuming repository import order survived the build.

Cascade layers can make the intended precedence stable across bundling.

Scenario 41: Reset Layer vs Component Layer

@layer reset, components;

@layer reset {
  button { border: 0; background: transparent; }
}

@layer components {
  .primary-button { background: navy; }
}

The component background wins because its normal layer comes later. The reset can use a type selector without forcing every component to outscore it. Layers express that reset rules are defaults, while component rules own the finished control.

Scenario 42: Responsive Visibility Utility

.desktop-only { display: block; }

@media (width <= 700px) {
  .desktop-only { display: none; }
}

The element disappears on narrow screens because the active declarations tie and the conditional rule comes later. If another utility sets display: grid !important, the responsive normal declaration loses. A utility system must define how responsive and important variants interact rather than relying on accidental file order.

Scenario 43: Disabled State vs Hover State

.button:hover { background: royalblue; }
.button:disabled { background: gray; }

A disabled button can still match pointer-related conditions in some situations, and both selectors have equal specificity. The later disabled rule wins here. A stronger design groups states explicitly and prevents disabled controls from presenting an active affordance. Source order is encoding product behavior, so that order should be documented and tested.

Scenario 44: Focus Indicator Removed by a Reset

:focus { outline: none; }
.button:focus-visible { outline: 3px solid currentColor; }

The focus-visible rule has greater specificity and restores an indicator for keyboard interaction. If the reset were important, the accessible rule would lose unless it also crossed that importance boundary. Broad focus resets are risky; component defaults should preserve a visible focus indicator instead of requiring later recovery.

Scenario 45: Reduced-Motion Preference

.spinner { animation: spin 1s linear infinite; }

@media (prefers-reduced-motion: reduce) {
  .spinner { animation: none; }
}

When the preference matches, the later equal-specificity declaration disables animation. A component rule with greater specificity could accidentally restore motion. Place accessibility preference overrides in an intentional layer or keep component selector weight low so user needs remain effective.

Scenario 46: Container Query Override

.product-card { grid-template-columns: 1fr 1fr; }

@container (width < 360px) {
  .product-card { grid-template-columns: 1fr; }
}

The query determines relevance based on the container rather than the viewport. When active, equal specificity and later order produce one column. If the container is not established or the query condition is false, no cascade battle occurs. DevTools container overlays help distinguish setup errors from selector conflicts.

Scenario 47: @import and Source Order

@import url("foundation.css");
@import url("components.css");

.button { color: navy; }

Imported rules participate as though inserted at their import position, subject to origin, layers, and other cascade stages. An equal unlayered rule after the imports wins by source order. Imports must appear before ordinary style rules under valid stylesheet grammar, and network timing does not rearrange their cascade order.

Scenario 48: CSS-in-JS Injects a Late Style Element

A component library inserts a style element at the end of the document head after the application stylesheet has loaded. Equal-specificity generated rules can win because their style element appears later. The fact that application source was imported later in JavaScript does not necessarily describe final CSS order.

Use the library's documented insertion point, theme API, or cascade layer support rather than repeatedly increasing selector weight.

Scenario 49: Route CSS Loads After Navigation

A single-page application loads a route-specific stylesheet only when the user opens that route. Its equal selectors appear after shared component CSS and change components that remain mounted outside the route. The result follows source order, but the broader match is an ownership defect.

Scope route selectors to a route boundary, use component-local classes, or assign route rules to a deliberate layer. Test client-side navigation as well as direct page loads because insertion order can differ.

Scenario 50: Print Styles Become Relevant

.navigation { display: flex; }

@media print {
  .navigation { display: none; }
}

In screen rendering, the print rule is irrelevant. During print preview it becomes relevant and wins the equal-specificity tie through later source order. An important screen utility could prevent the navigation from hiding, so print behavior should be inspected with the actual print media mode.

Scenario 51: Pseudo-Element Owns the Visible Color

.badge { background: blue; }
.badge::before { background: red; content: ""; }

If the generated pseudo-element covers the badge, changing the element's background may appear ineffective even though blue wins on the element. The declarations target different boxes and do not conflict. Select ::before in DevTools and change the rule that owns the visible layer.

Scenario 52: all: unset Removes Expected Defaults

.plain-button {
  all: unset;
  cursor: pointer;
}

The all shorthand assigns unset to nearly every property, causing inherited properties to inherit and other properties to use initial behavior. Later component rules can restore individual values, but native button display, typography, and focus appearance may already be removed. Use broad resets carefully and rebuild accessible states deliberately.

Scenario 53: User Contrast Override

A user stylesheet applies color: CanvasText !important to improve readability, while the site uses color: gray !important. The user important rule wins over the author important rule because important origin order is reversed to protect user needs. Adding an ID or inline important author style should not be used to fight that preference.

Design components so icons, borders, and text remain understandable when user-selected colors replace author colors.

Scenario 54: Feature Query Fallback

.gallery { display: flex; }

@supports (display: grid) {
  .gallery { display: grid; }
}

A browser supporting Grid considers both declarations and chooses the later equal-specificity value. A browser without support excludes the conditional rule and keeps Flexbox. The query does not make its rule intrinsically stronger; it determines whether that rule is relevant. A higher-specificity flex declaration could still win inside a supporting browser.

Scenario 55: Importing Vendor CSS Into a Layer

@import url("vendor.css") layer(vendor);
@layer components;

@layer components {
  .button { color: navy; }
}

The import places vendor declarations inside a controlled layer. With vendor ordered before components, normal component declarations can override even highly specific vendor selectors. This avoids editing vendor code and reduces the need for important overrides. Confirm layer order declarations are established consistently across entry stylesheets.

Scenario 56: Rolling Back the Current Layer

@layer base, theme;

@layer base {
  .notice { color: navy; }
}

@layer theme {
  .notice { color: revert-layer; }
}

The theme declaration rolls back values supplied by its own layer for that property, allowing the lower base layer to provide navy. revert-layer is different from initial and inherit; it asks the cascade to ignore the current layer's contribution rather than choosing a generic default.

Scenario 57: Inline Custom Property With External Component Rules

<div class="meter" style="--value: 68%;"></div>

.meter {
  inline-size: var(--value);
  background: seagreen;
}

The inline declaration strongly sets only the instance token, while the external class owns reusable presentation. A theme can still change the background without competing with an inline background value. This hybrid pattern confines inline precedence to dynamic data and keeps responsive or state behavior in the stylesheet.

Combined E-Commerce Button Scenario

<button id="checkout" class="btn primary">Checkout</button>

button { background: gray; }
.btn { background: blue; }
.primary { background: green; }
#checkout { background: orange; }

@media (width <= 768px) {
  .primary { background: purple; }
}

On desktop, the ID wins and the button is orange. On mobile, the purple rule becomes relevant, but it still loses to the ID because media queries do not add priority. A durable redesign removes the ID from presentation ownership and uses a component variant or a later layer for responsive behavior.

Combined Framework, Component, and Utility Scenario

@layer vendor, components, utilities;

@layer vendor {
  #app .btn { padding: 8px; }
}

@layer components {
  .button { padding: 12px; }
}

@layer utilities {
  .p-compact { padding: 6px; }
}

An element matching all three gets six pixels because the utility layer is strongest for normal declarations. Neither the vendor ID nor the component's source order can cross the layer boundary. This architecture communicates intent more clearly than escalating selectors.

Combined Theme Token Scenario

:root {
  --surface: white;
  --text: #172033;
}

[data-theme="dark"] {
  --surface: #151922;
  --text: #f5f7fa;
}

.card {
  background: var(--surface);
  color: var(--text);
}

The theme changes inherited tokens, and the card continues to own its final properties. This avoids separate high-specificity theme rules for each component and makes cascade ownership easier to inspect.

Practical Debugging Order

Start by selecting the exact element and property in DevTools. Confirm the expected selector matches and all conditions are active. Find the winning declaration, then compare origin and importance, shadow context, and layer order. Calculate specificity only among candidates still tied. Check scope proximity and source order last.

If the winning computed value is correct but the appearance is wrong, investigate inheritance, custom properties, shorthand expansion, animation, transition, layout, and paint. Randomly adding weight hides the real cause.

Architecture Lessons From the Scenarios

Keep component selectors low and stable, use classes instead of presentation IDs, and place vendor, foundation, component, and utility rules in documented layers. Use :where() for weak defaults and tokens for theme or variant values. Reserve important declarations for deliberate guarantees.

Most cascade problems become manageable when every rule has an owner. A stylesheet should explain whether a value is a default, component decision, state, theme token, or explicit utility override.

Interview Questions and Answers

Does a media query automatically override normal CSS? No. It controls whether declarations participate; active declarations still follow the cascade.

Can a class override an ID? Yes when an earlier cascade stage decides it, such as a stronger normal layer or important declaration. Specificity alone favors the ID.

Does internal CSS beat external CSS? No. With all else equal, their combined source order decides.

Does inherited style beat a direct declaration? No. A direct cascaded value on the child wins over inheritance.

Why can a later rule still lose? Importance, origin, context, layer, specificity, or scope proximity may have already decided the winner.

Practical Review Checklist

• Confirm every competing selector and condition is relevant.
• Compare origin and importance before selector specificity.
• Inspect shadow context and cascade layer names.
• Remember that important layer order reverses.
• Calculate specificity using the A-B-C model.
• Use source order only after all earlier factors tie.
• Separate direct declarations from inherited values.
• Expand shorthand properties and trace custom-property values.
• Inspect animations and active transitions.
• Test state combinations and responsive conditions.
• Review the delivered production bundle order.
• Prefer layers, tokens, and low specificity over escalation.

Key Takeaway

Real-world cascade behavior is predictable when conflicts are evaluated in the browser's order. Relevance decides which rules enter the contest. Origin, importance, context, and layers can resolve it before specificity. Scope proximity and source order settle only the remaining ties, while inheritance and defaulting provide values afterward.

The practical goal is not to memorize isolated winners. It is to recognize which stage owns each scenario and design styles so that ownership remains obvious. With purposeful layers, modest selectors, reusable tokens, and evidence from DevTools, framework overrides, responsive states, utilities, themes, and component variants can coexist without becoming a specificity race.