A colour refuses to change. You make the selector longer, move the rule to the bottom of the file and try again. The browser still chooses the other declaration. The useful question is which comparison decided the result before your new selector was even considered.
The short answer is that cascade layers establish priority before selector specificity. Within the same origin, later layers win for normal declarations, while earlier layers win for important declarations. Unlayered stylesheet declarations sit above named layers for normal declarations and below them for important declarations. Inline styles and other origins need their own comparisons.
This lesson builds an original notice-card example, changes one condition at a time and follows the winning declaration. The colours are labels for tracing the algorithm, not a recommended colour scheme or an accessibility assessment. Begin with the Websites subject guide for the wider responsibility to make a website clear, usable and dependable.
eduKateSG · Websites
Find your next learning step
Keep applicability, origin, importance, layer order, specificity and the actual result distinct.
ROUTE 1 · CHAPTERS 1–5
Set up the comparison
Build the first-principles model and follow the central original example.
ROUTE 2 · CHAPTERS 6–10
Work the priority cases
Change one condition and preserve the accounting at each step.
ROUTE 3 · CHAPTERS 11–15
Follow the architecture
Include the additional inputs that alter a real component.
ROUTE 4 · CHAPTERS 16–19
Diagnose and transfer
Test predictions and identify the limits of the simplified model.
ROUTE 5 · CHAPTERS 20–22
Check and continue
Use independent checks, useful questions and verified onward routes.
Chapter contents
Set up the comparison · Chapters 1–5
1. Begin with one element and one property
2. Separate relevance from priority
3. Establish the layer order deliberately
Work the priority cases · Chapters 6–10
6. Add an unlayered normal rule
7. Reverse the comparison for important declarations
8. Mix normal and important candidates correctly
Follow the architecture · Chapters 11–15
11. Preserve the distinction between author and user origins
12. Reopening a layer does not move it
13. Read nested layers as a hierarchy
14. Plan a legacy-style migration without selector escalation
Diagnose and transfer · Chapters 16–19
16. Diagnose with evidence from the actual browser state
17. Understand the limits of a winning declaration
Check and continue · Chapters 20–22
20. Design a diagnostic change with a predicted outcome
A cascade question concerns a particular property on a particular element in a particular state. Saying that one stylesheet wins is usually too broad. A card can receive its colour from one rule, its padding from another and its border from a third. Start by naming the element and the property whose result you want to explain.
Our fictional page contains a paragraph with class notice inside a section with id board. We examine its color property. Every example assumes a normal light DOM document, matching selectors, applicable stylesheets and valid colour values. There are no shadow trees, scoped rules, animations or transitions unless a chapter explicitly introduces that boundary.
Imagine three contributors to the page: a foundation stylesheet, a reusable component stylesheet and a local adjustment stylesheet. Their filenames describe responsibilities, but filenames do not determine cascade priority. A file called overrides.css has no special power simply because its name sounds decisive. The declarations and their actual placement determine the result.
Write a small question before changing code: why is this paragraph green when I expected blue? Record the current matching declarations. This gives the investigation a fixed target. If you change the HTML structure, rename the class and move several rules simultaneously, you may obtain a different appearance without learning which original assumption was wrong.
A declaration that does not apply to the element does not enter the same competition as one that does. A selector may fail to match; a media condition may be false; a stylesheet may not have loaded; a declaration may be invalid. These are eligibility questions, and they come before comparing the eligible candidates.
Suppose the component stylesheet contains a blue notice rule inside a print-only media query. On the ordinary screen view, that rule cannot win merely because its layer is later. Changing layer order does not turn a print rule into a screen rule. Similarly, a misspelt class name cannot be repaired by adding importance to its declaration.
For a practical check, inspect the element and confirm the rule is actually among its applicable styles. If it is absent, investigate matching, loading and conditions. If it appears but loses, investigate priority. These two observations lead to different repairs, so keep them separate in your notes.
The same distinction helps a student explain a failed experiment. A predicted colour change that never appears is not automatically evidence against the cascade rule being studied. First establish that the changed declaration was eligible under the test conditions. A controlled comparison holds the element, browser state and applicability constant while changing the chosen priority factor.
For the central example, declare three layers in this order: foundation, components, adjustments. The statement establishes their relative order before their bodies appear. Think of this as an ordered set of compartments within the author stylesheet origin. The compartment matters before the selector is compared with selectors in other compartments.
An illustrative ordering statement is @layer foundation, components, adjustments;. A later @layer components block contributes rules to that existing layer. It does not move components after adjustments just because its block appears later in the file. The first establishment of the layer order remains relevant to every later contribution.
This makes an important experiment possible. Put a components block near the bottom of the stylesheet and an adjustments block near the top, after the ordering statement. Their physical order may look surprising, but a normal declaration in adjustments still has the later layer position. You must distinguish block location from established layer position.
The W3C cascade specification supplies the normative layer-order rules. Our three names are an original teaching arrangement. They are not reserved words or a universal architecture. A real project can choose other names, but the team should be able to identify where the order is first established and which rules remain outside it.
Suppose foundation sets color to red using the selector #board .notice. Components sets color to blue using .notice. Adjustments sets color to green using p. All three selectors match our paragraph, all three declarations are normal, and each belongs to its stated layer. Which colour should the paragraph receive?
The answer is green. Within this same origin and importance level, adjustments is the later layer. The foundation selector contains an id and a class, but that extra specificity cannot defeat a declaration in a layer with higher normal priority. The comparison has already been decided before the selector tuples would become relevant.
Now remove the green declaration completely. Blue wins over red because components follows foundation. This second result is useful because it shows that the first outcome did not depend on green being a special colour or p being a special selector. The same structural comparison selects the later remaining normal layer.
Before reading further, predict the result if foundation changes its selector to #board #board .notice while components keeps .notice. Under our matching assumptions, blue still wins. Making an already losing layer’s selector more specific changes a later comparison that this pair never reaches. The repair must address the actual priority boundary rather than increase an irrelevant quantity.
CHAPTER 5 OF 22 · Set up the comparison
5. Compare specificity inside the surviving layer
Layers do not eliminate specificity. They determine which declarations are allowed to reach that comparison. Add two normal declarations inside adjustments: .notice sets green, while #board .notice sets purple. Now both candidates occupy the same origin, importance level and layer. Their selector specificity can decide the result, so purple wins.
For these simple selectors, the relevant specificity tuples are zero ids, one class, zero type selectors for .notice, and one id, one class, zero type selectors for #board .notice. Compare the components in order. The id difference decides this pair. Treating specificity as an informal score can encourage mistaken arithmetic across different components.
Then place another #board .notice rule later in that same layer, setting orange. With the earlier conditions and specificity equal, later appearance decides this simplified example. Orange wins. We have reached source order only after the preceding comparisons tied; source order was never an all-purpose instruction to ignore those comparisons.
The Selectors specification explains selector specificity. This lesson deliberately uses ordinary selectors so the layer reasoning remains visible. Functional selectors, nesting and other features need their specified specificity rules. Do not infer that counting every punctuation mark or every word in a selector produces its correct priority.
Return to one normal colour declaration in each named layer, with green in adjustments. Now add an unlayered stylesheet rule p { color: black; }. Under our author-origin assumptions, black wins. Normal unlayered stylesheet declarations take priority over normal declarations in the named layers, even when their selectors are less specific.
This explains a common migration surprise. A team introduces layers around its carefully organised component styles but leaves an old global rule outside every layer. The old rule can defeat the newly layered normal declarations. The layered code is being evaluated; its compartment simply has lower normal priority than the unlayered declaration.
Moving that global rule to the top of the file does not necessarily help. Its unlayered status still matters before source order. Likewise, adding a stronger selector to the component is an unreliable response when the competitor remains in a higher normal compartment. Document the layer membership as well as the line number.
A controlled repair can place the legacy rules in an intentionally earlier layer, then verify the affected components. That is an architectural change, not a cosmetic relocation. It may alter many existing comparisons, so a real site needs representative checks. The classroom example establishes one result; it does not prove that moving an entire production stylesheet is harmless.
CHAPTER 7 OF 22 · Work the priority cases
7. Reverse the comparison for important declarations
Now mark the red, blue and green colour declarations important, and remove the unlayered black rule. Foundation wins, so the paragraph becomes red. The earliest layer has higher priority among important declarations in the same origin. This is the reversal that makes a simple later-layer-always-wins slogan unreliable.
The reversal does not reverse every part of the cascade. It does not mean that less specific selectors automatically beat more specific selectors inside a layer. Nor does it mean the first declaration in a layer always wins a source-order tie. Identify the particular ordering being reversed: the relative priority of layers for important declarations.
Put two important declarations in foundation, one on .notice and one on #board .notice. The more specific matching selector still wins within that layer under the other simplifying conditions. If matching specificity ties there, later appearance remains relevant. Reversal at one stage should not be casually applied to another stage.
MDN's @layer reference provides a practical companion to the specification. Our examples isolate the consequence through named declarations. Write the predicted winner before adding the annotation, then compare. A correct prediction with a clear reason is stronger evidence of understanding than repeatedly editing until a preferred colour appears.
CHAPTER 8 OF 22 · Work the priority cases
8. Mix normal and important candidates correctly
Suppose foundation contains a normal red declaration, components an important blue declaration, and adjustments a normal green declaration. Blue wins. Do not first select adjustments as the later normal layer and then ask whether its selector is strong enough. The important declaration belongs to a higher importance category in this author-only example.
Next, make foundation’s red declaration important as well. Red now wins over blue because both relevant candidates are important and foundation is the earlier layer. The normal green declaration remains unable to compete with these important author declarations. The sequence of comparisons has changed which subset survives, not merely assigned a different point total to every rule.
Add an important unlayered black declaration. Red still wins: important declarations in the named layers take priority over important unlayered stylesheet declarations within this origin. If you remove the two layered important declarations, black wins over the remaining normal rules. These two tests distinguish importance from layer position.
Record the result as a reasoned statement: foundation’s important red declaration wins among author stylesheet declarations because the important named-layer order is reversed. This is more precise than saying red is strongest. It tells another reader which assumptions to challenge if their page produces a different result, including whether another origin, inline declaration or active transition is present.
A ledger can make a surprising result easy to review. Give each candidate an identifier, property, value, origin, importance flag, layer and selector. Note whether it matches. You do not need a large spreadsheet for three rules, but you do need enough information to compare the same property on the same element.
For our example, the ledger records foundation red, components blue, adjustments green and unlayered black. With all normal, black wins. With every declaration important, foundation red wins. With only components important, blue wins. The values stay the same while the importance configuration changes, making the mechanism easier to see.
| Configuration | Winning stylesheet declaration | Deciding comparison |
|---|---|---|
| All four normal | Unlayered black | Normal unlayered priority |
| All four important | Foundation red | Earlier important layer |
| Only components important | Components blue | Importance before normal layer order |
| Normal named layers only | Adjustments green | Later normal layer |
This is a fictional declaration ledger, not a full cascade table. It intentionally excludes inline styles and other origins, which the next chapters distinguish.
Use the ledger to test explanations, not just answers. If someone predicts black in the all-important case because it is unlayered, they have carried the normal ordering into the important comparison. If they predict foundation red in every case because its selector has an id, they have placed specificity too early. Each mistake suggests a different short correction.
CHAPTER 10 OF 22 · Work the priority cases
10. Recognise the separate place of inline styles
An element’s style attribute is not simply another unnamed stylesheet rule. Suppose our paragraph has a normal inline color declaration of brown. It takes priority over the normal author stylesheet declarations in this example, including the unlayered black rule. Treating the style attribute as a named layer would misdescribe the comparison.
An important author stylesheet colour can nevertheless beat that normal inline colour. If the inline colour itself is important, it has priority over other important author declarations. These statements remain within the author origin; they are not a claim that inline importance defeats every possible user or browser rule.
This matters when investigating a component library or an editor that writes style attributes. You may inspect the external stylesheet accurately yet miss the value attached directly to the element. Before escalating selectors, check the element’s current attributes and whether script updates them. The relevant state is the document being rendered, not only a source file saved earlier.
For a transfer exercise, take our all-normal ledger and add inline brown. Predict brown. Then make components blue important while leaving inline brown normal: predict blue. Finally make inline brown important: predict brown within the stated author-only competition. You have changed one classification at a time and preserved a reproducible explanation for each result.
CHAPTER 11 OF 22 · Follow the architecture
11. Preserve the distinction between author and user origins
A visitor’s browser environment can include user styles in addition to the website’s author styles. The origin comparison is part of the cascade. An important user declaration can take priority over important author declarations. A website’s early layer cannot turn an author declaration into a user-origin declaration merely by naming it accessibility.
This is a useful boundary for site owners. Layer architecture can organise the site’s own rules, but it does not grant a promise of absolute visual control. Readers may need presentation changes. The cascade’s origins and importance rules exist within that wider environment, so a demonstration restricted to author rules must say so.
Suppose our fictional exercise adds a matching important user colour chosen for the reader’s needs. The earlier-layer author red is no longer the winner merely because it led the author-only ledger. Start at the origin-and-importance comparison again rather than carrying the previous winner forward as an unquestioned fact.
MDN's cascade introduction gives the broader ordering, including origins, inline styles, animations and transitions. The central lesson remains a bounded one: layers are a priority mechanism within that system. A good explanation names the boundary instead of replacing the entire cascade with the much smaller table that happened to solve one classroom example.
Imagine one component file contributes a blue notice rule to components and another later file contributes a teal notice rule to components. The second contribution joins the existing layer. It does not create a second independent components layer after adjustments. Reusing the same layer name and establishing a new layer are different actions.
Within components, the additional declaration can affect comparisons governed by specificity and appearance. Across components and adjustments, the established layer order remains. This gives us a two-level question: which layer survives, and which declaration survives inside that layer? Keeping the levels separate prevents a late import from being mistaken for a layer-order reset.
Try this paper experiment. Establish foundation, components, adjustments. Write one normal adjustments rule at the beginning of the file and append ten components blocks later. Provided no other assumptions change, the later-layer adjustments declaration still wins their cross-layer competition. The number of components blocks does not accumulate into greater authority.
This also improves review comments. Instead of asking why a file was placed earlier, ask whether the placement changes a within-layer tie or the first declaration of a layer name. The same textual movement can have different effects depending on what has already been established. A useful change description identifies which relationship it intends to alter.
A project can nest layers. For a bounded example, foundation contains reset and tokens sublayers, while components contains cards and forms. The top-level distinction still matters. A normal declaration in a foundation sublayer does not leap above a later top-level components layer because its local sublayer name sounds more important.
Work from the shared outer hierarchy before comparing the inner branches. Within foundation, reset and tokens have their own relative order. Within components, cards and forms have another. A priority statement about two sibling sublayers should not be applied directly to declarations that occupy different top-level parents.
For a paper check, label two declarations foundation.tokens and components.cards. In the ordinary normal-author comparison, components is later at the top level, so components.cards survives before any attempt to compare tokens with cards as if they were siblings. Then compare two candidates both inside components to reach the relevant internal ordering.
Keep the actual architecture modest. More layers do not automatically produce a better website. If a learner cannot tell which parent contains a rule, extra hierarchy can conceal the intended relationship. Use a small diagram or written path during investigation, and confirm the path against the actual stylesheet. Names should help people find the priority decision rather than become a second system of unexplained jargon.
CHAPTER 14 OF 22 · Follow the architecture
14. Plan a legacy-style migration without selector escalation
Suppose a fictional site has a large unlayered legacy stylesheet and a new layered card component. The component’s normal rules lose to matching legacy normal rules. A tempting response adds ids to every component selector. Our earlier example predicts why that response may leave the cross-layer problem unchanged.
A more useful investigation lists the specific conflicting properties and identifies where the legacy stylesheet could be placed intentionally. In a disposable copy, moving legacy rules into an earlier layer can allow later normal component rules to take priority. But important declarations reverse that layer ordering, so their existing uses need separate review.
Do not move a stylesheet and judge success from one card. Check representative navigation, forms, focus indicators, expanded sections and error states affected by those rules. Also inspect rules deliberately left unlayered. The experiment’s success criterion is the intended behaviour across the scoped change, not merely a preferred screenshot on the first page.
The practical output is an explicit priority agreement: which layer supplies defaults, which supplies components, which supplies local adaptations and how important exceptions are handled. The agreement should match the code. A document claiming adjustments always win would teach maintainers the wrong rule as soon as important declarations enter the same comparison.
CHAPTER 15 OF 22 · Follow the architecture
15. Check a property rather than an entire rule block
A style rule can contain several declarations, and they can lose for different reasons. In a fictional card, components might supply the winning padding while adjustments supplies the winning colour. An important border declaration in foundation may survive both. The browser is resolving properties, not awarding the entire card to one stylesheet.
Build three separate ledgers for color, padding and border-width. Keep the matching element constant, then list only the candidates for the chosen property. This small discipline prevents a visual change in one property from being used as evidence about a different property whose competitors and importance flags differ.
Shorthand declarations deserve extra care because they affect their longhand properties. A later shorthand can contribute a value to a longhand you were inspecting, even when the shorthand’s name looks unrelated to the specific side or component in question. Inspect the expanded longhand information where your developer tools provide it, and follow the applicable property rules.
For a learner, explain the finished card in three sentences: where its text colour came from, where its spacing came from and where its border came from. If the explanation repeatedly says the same file controls everything without evidence, return to the ledgers. A modular stylesheet can intentionally combine several sources in one element while remaining predictable.
CHAPTER 16 OF 22 · Diagnose and transfer
16. Diagnose with evidence from the actual browser state
Begin by selecting the exact element, including its relevant state. Inspect matched rules and the computed result for the property. Locate the declaration you expected to win, then identify whether it is missing, inactive, overridden or supplying a value that later behaves unexpectedly. These observations narrow the question before any repair.
The Chrome DevTools CSS reference documents matched and computed style inspection. Other browsers provide their own tools. Labels and interface details can change, so learn the evidence you need rather than relying on the permanent location of a particular button. A crossed-out declaration alone still requires an explanation of the competition.
Record the stylesheet location, layer, importance, selector and relevant conditions for the winning and expected declarations. Then predict a single controlled change. For example, removing an unintended unlayered normal competitor should expose the later normal named-layer winner in our isolated exercise. Compare the observed result with that prediction before making additional changes.
If the result differs, preserve the failed prediction. It is evidence that an assumption was incomplete: another rule, inline value, state, origin or dependency may be involved. Guessing a new selector immediately throws away that evidence. A careful investigation makes the hidden condition visible and produces an explanation someone else can reproduce.
CHAPTER 17 OF 22 · Diagnose and transfer
17. Understand the limits of a winning declaration
Finding the winning declaration answers a cascade question. It does not prove that the resulting value is valid after every later processing step, that the layout is usable or that text has sufficient contrast. These are connected questions with their own evidence. A successful layer prediction is useful without being a complete website assessment.
For instance, a declaration using a custom property can win the cascade and still encounter a problem when its substituted value is evaluated for the destination property. Increasing specificity cannot repair a token that is unsuitable for that property. Keep the priority diagnosis distinct from the value diagnosis and inspect the computed result.
Likewise, a text colour can be correctly selected by the cascade yet be difficult to read against the actual background. Our named colours are only visible labels for an algorithm exercise. A real interface needs the appropriate contrast, states and user checks. The design question is what the reader can perceive and do with the resulting page.
This boundary prevents an overclaim in a student’s report. Write that the isolated examples matched the predicted layer comparisons under their stated conditions. Do not write that the site is accessible or all styling conflicts are solved. The strongest report states what was tested, the mechanism explaining it and which separate checks remain necessary for the intended user task.
CHAPTER 18 OF 22 · Diagnose and transfer
18. Use changed-context checks to test transfer
Take an unfamiliar set of layer names: vendor, theme, local. A normal vendor declaration uses an id selector; a normal local declaration uses a class. With all earlier assumptions held, local wins. Renaming the layers has changed the vocabulary without changing the structure. A learner who understands the comparison can explain the same result.
Now make both declarations important. Vendor wins because it is the earlier important layer. Finally add an important unlayered stylesheet declaration with a much more specific selector. Vendor still wins that author stylesheet comparison. The selector difference remains a later comparison that these candidates do not reach.
For a second check, put both important declarations into local instead. The more specific matching selector can now matter because the layer distinction has disappeared. If they have equal specificity and all other relevant comparisons tie, later appearance decides our simplified case. This version tests whether the learner can stop applying the cross-layer rule once the candidates share a layer.
Explain each answer by naming the deciding stage and one irrelevant change. For example: moving the losing important declaration later does not change its layer’s position. This kind of explanation transfers beyond memorised colour outcomes. It shows that the learner can identify which part of the system a proposed repair actually changes.
The first misleading explanation says the rule at the bottom always wins. Repair it by identifying what must already tie before appearance decides the result. In our ordinary same-origin examples, importance, layer and specificity can decide earlier. Scoped rules and other environments introduce further specified comparisons that our simple exercise excludes.
The second says an id selector defeats a class selector. Repair it by adding the comparison’s scope: specificity is relevant among candidates that survive the preceding priority stages. Our normal components class defeated foundation’s id-containing selector because the later layer decided their competition. The selector statement alone had omitted a decisive condition.
The third says important means the declaration defeats everything. Repair it by identifying origin, layer ordering and inline distinctions, and by recognising active transitions as a further boundary in the wider cascade. Importance is a defined classification within an algorithm. Its ordinary-language meaning should not be substituted for that algorithm.
A useful classroom response asks for a counterexample with only the necessary moving parts. Use two declarations where possible, state the element and property, and change one condition. A small counterexample explains more than a large collection of styles whose interactions nobody has tracked. The goal is a model that predicts a new case before the browser displays it.
CHAPTER 20 OF 22 · Check and continue
20. Design a diagnostic change with a predicted outcome
Imagine a fictional component whose normal blue declaration is in components, while a normal red legacy declaration remains unlayered. The page is red. Before editing, write two proposals and predict each result. Proposal one doubles the component selector’s class conditions while preserving a match. Proposal two moves the red legacy declaration into foundation, whose order was established before components.
Under our stated author-only conditions, proposal one leaves red winning because the unlayered distinction is resolved before specificity. Proposal two allows the later normal components layer to win, so blue appears. This pair is useful because both changes look like reasonable attempts to make component styles take priority, but they act at different stages.
Now make the red legacy declaration important before trying either proposal. The expected normal-versus-important comparison changes the answer again. Moving the important red declaration into an earlier layer does not let a normal blue declaration defeat it. The controlled repair must address the actual intended importance architecture rather than reuse an answer from the all-normal exercise.
Keep the predicted outcomes with the change record. If a proposed repair produces the right colour for the wrong predicted reason, inspect the actual winning declaration before accepting the explanation. Another accidental override may be hiding the original conflict. A useful experiment establishes both an outcome and the mechanism responsible, so a later maintainer can understand what will happen when a neighbouring rule changes.
Does the last named layer always win? It wins the normal-declaration comparison against earlier named layers within the same origin, provided higher-priority distinctions do not decide first. Important declarations reverse that layer order. Unlayered stylesheet declarations and inline styles also need their correct places in the comparison.
Does reopening a named layer move it? No. Contributing more rules to an existing layer does not itself establish a new position for that layer. The additional rules can affect comparisons within it. Check where the layer order was first established rather than infer priority solely from the final block’s line number.
Should every conflict be repaired with an important annotation? First identify why the intended declaration loses and whether the intended priority architecture is correct. An annotation changes the importance category and can reverse the relevant layer comparison. It may produce one desired result while making later changes harder to reason about.
Can a developer-tools edit prove that a published fix is saved? No. A temporary edit can test a hypothesis in the current page state. The actual source change must be saved through the appropriate project process, loaded again and checked in the intended environments. Inspect the resulting page rather than assume the experiment and the released files are identical.
Style priority and token values
Why a Variable Fallback Cannot Repair Every Invalid Property Value.
Space and visual sequence
Tracing Dense Grid Placement Without Confusing Visual and Document Order · Redistributing Flex Shrink When Items Reach Their Minimum Sizes.
For purpose, maintenance and usable journeys, return to the Websites subject guide. For the wider rendering pipeline, read Web Browsers, Layout Geometry, Pixels and Rendering. That article introduces layout, paint and compositing; cascade layers are a different concept from the graphics surfaces a browser may composite.
For the consequences a visitor experiences, continue into Web Accessibility and Digital Accessibility Testing Services. Correctly selected CSS is an input to those checks, not a replacement for them. For dependable changes across a project, use Software Engineering.
Primary reading: W3C cascade layers, selector specificity, MDN's layer reference, the broader cascade and browser style inspection. Sources checked on 27 October 2026. All notice-card cases are original teaching constructions.
Continue through How X Works and Learning That Transfers into Life by predicting an unfamiliar result, identifying the decisive comparison and checking the actual outcome. The useful achievement is a reasoned repair that survives a change of names, selectors and importance flags.