If your child changes a colour in a stylesheet and the page stubbornly stays the same, another random selector is unlikely to solve the learning problem. CSS specificity becomes much easier when the learner first asks which declarations actually compete, then compares the selectors in the correct order. A small page with two conflicting rules can teach more than a large project filled with patches.
CSS specificity is the selector weight used within the browser's cascade to help choose a winning declaration. It is commonly expressed through three columns: IDs, classes and related selectors, and element types. This guide explains the specificity calculation, why later code does not always win, and why cascade layers and importance must be considered before selector weight. The examples are small enough for a Punggol learner to inspect one decision at a time.
For parents considering support for web-development learning alongside Punggol tuition, the useful question is not whether a child can make a colourful page. Ask whether they can explain why one rule wins, repair a conflict without making the next conflict harder, and leave a readable stylesheet. These are practical enrichment activities, rather than a claim that a particular web-development course is offered or required by the student's school.
Choose your next learning step
1. Start with a real competing pair
Imagine a paragraph with the class notice. One rule gives all paragraphs a blue colour. Another gives elements with the class notice a green colour. Both selectors match the paragraph, both set the same property, and both declarations are normal author styles in the same layer. Under those conditions, the class selector has greater specificity and green wins.
The conditions matter. The browser is not conducting a universal contest between every selector in every file. It resolves declarations for an element and property after considering which rules are applicable and where those declarations sit in the cascade. A rule that does not match the element cannot win its colour.
p { color: blue; }
.notice { color: green; }For a first lesson, use a page containing one paragraph and one stylesheet. Confirm that the paragraph actually has class notice. If it does not, the green declaration never enters the competition. This is a selector-matching problem, not a specificity problem.
Ask the student to make a prediction before refreshing the page. Then ask for the reason in a sentence that names the property and the competing selectors. “Green because classes beat element selectors here” is more useful than “green because the computer prefers it.”
2. Check whether the rule can apply at all
Before comparing specificity, inspect the selector, the property and the condition surrounding the rule. A misspelt class does not match. A declaration inside an inactive media query does not participate at that viewport. A property value that is invalid for the browser is not a usable competing declaration.
This first check prevents many unnecessary repairs. A student may add an ID to overpower another rule when the real problem is an incorrect filename or an unloaded stylesheet. Increasing selector weight cannot fix a file that the browser never received.
Use a short diagnostic sequence. Confirm the HTML element. Confirm that the stylesheet is loaded. Confirm that the selector matches. Confirm that the declaration is valid. Confirm that any media or support condition applies. Only then ask which competing declaration wins.
For a Punggol student making an imaginary reading-club page, use a visible notice and two rules. Change the class name deliberately in the HTML and observe what happens. The exercise separates absence of a match from loss in a contest. Both can look like “my style is not working,” but the repairs are different.
A parent does not need to understand every browser panel to ask the useful question: “Have you checked that this rule is actually reaching that element?” That keeps the conversation focused on evidence rather than repeated changes.
3. Calculate the three specificity columns
For ordinary selector comparison, count ID selectors in the first column, class selectors, attribute selectors and pseudo-classes in the second, and type selectors and pseudo-elements in the third. Compare the columns from left to right. The first differing column decides the higher specificity.
The selector #schedule has specificity one-zero-zero. The selector .notice has zero-one-zero. The selector p has zero-zero-one. Combining selectors adds their contributions within a selector: section .notice has zero-one-one.
The columns are not a decimal number. Ten class selectors do not turn into one ID selector. A selector with one ID has greater specificity than a selector with no IDs, however many classes the latter contains. This is a priority comparison, not a carrying arithmetic system.
Practise with three short selectors before attempting a long chain. For article p, count two type selectors. For .card .title, count two classes. For #page .title, count one ID and one class. Then compare them by looking at the ID column first.
A good learner can explain both the count and the comparison. Someone who has memorised that one particular selector wins may still be unable to read a new selector. Keep the contribution of each piece visible until the calculation becomes reliable.
4. Avoid the misleading points shortcut
Some beginner explanations assign a hundred points to an ID, ten to a class and one to an element. That can be a quick illustration for small examples, but it becomes misleading when students treat the sum as a general numerical score. The specificity columns do not carry into one another.
Consider a selector containing eleven classes and no ID. Its specificity begins with zero. A selector with one ID begins with one and wins the specificity comparison under otherwise equal cascade conditions. Adding up eleven tens would give a misleading result if treated as a normal decimal score.
Teach a tuple or a three-column table instead. Write the ID count, class-related count and type-related count separately. Ask which leftmost column differs. Only if the ID counts tie should the class-related counts be compared. Only if those also tie should the element counts decide.
This connects nicely to careful comparison in Mathematics without forcing the two systems to be identical. Students already recognise that a comparison rule determines which information matters first. Here, the browser's rule is lexicographic: compare one column, then the next if necessary.
Once the learner uses the columns comfortably, long selectors become readable. The lesson is not to produce heavier selectors. It is to understand the weights well enough to choose simpler, more maintainable rules.
5. Count attributes and pseudo-classes correctly
An attribute selector contributes to the class-related column. For example, [data-state="ready"] has zero-one-zero specificity. Adding an element type gives button[data-state="ready"] specificity zero-one-one. The attribute's value does not add extra weight.
Ordinary pseudo-classes such as :hover, :focus and :disabled also contribute to the class-related column. The selector .action:hover has zero-two-zero: one contribution for the class and one for hover. That explains why an interaction rule can outweigh a simple base class.
Pseudo-elements such as ::before and ::after contribute to the type-related column instead. The selector .notice::before has zero-one-one. Students who count both kinds as classes will predict some competitions incorrectly.
There are exceptions for functional pseudo-classes such as is, not and where, which need their own chapter. Do not introduce a simplified rule as if it has no exceptions. Start with ordinary pseudo-classes, then identify the special forms explicitly.
For practice, compare button.action, .action:hover and button[data-state="ready"]. The first and third each have zero-one-one, while the hover selector has zero-two-zero. Under equal cascade conditions, the second wins specificity because the middle column is higher.
6. Recognise what does not add specificity
The universal selector * does not add specificity. Combinators such as the descendant space, child symbol, adjacent sibling symbol and general sibling symbol also do not add weight. They change which elements match, but the counted selectors supply the specificity.
Compare .panel p and .panel > p. Each has one class and one type selector, so each has zero-one-one specificity. The child combinator narrows the structural relationship; it does not raise the weight. Narrower matching and higher specificity are different ideas.
This distinction is important for students who describe a selector as “more specific” in everyday English. A selector can match fewer elements without having a larger CSS specificity tuple. The technical calculation has its own definition.
.panel p { color: navy; }
.panel > p { color: maroon; }If a paragraph is a direct child of panel, both rules match. With the same origin, importance and layer, and no scope difference, their specificity ties, so the later rule wins. If the paragraph is nested inside another child, the second rule does not match, and the first may apply.
Ask the learner to explain both cases. This checks selector matching and cascade comparison separately, which is exactly what real debugging requires.
7. Use source order only after the earlier decisions tie
The last matching declaration can win, but only after the relevant earlier cascade comparisons have tied. If two normal declarations in the same author layer have equal specificity and equal scoping proximity, the later declaration wins. This is the useful beginner rule with its conditions made visible.
A class rule earlier in the stylesheet can defeat a later type rule because the specificity differs. Moving the type rule down again will not change that comparison. Students who rely only on “last line wins” often respond by duplicating rules repeatedly.
.notice { color: green; }
p { color: blue; }The paragraph with class notice remains green under the simple same-layer conditions. The later p rule has lower specificity. To change the notice intentionally, use an appropriately placed notice rule or reorganise the stylesheet; do not expect the type selector to win merely because it appears later.
For a tied example, use two notice rules with different colours. The second wins because the earlier checks tie. Label the examples carefully so the student sees why source order matters in one and not the other.
A helpful debugging explanation ends with the deciding factor: “The class counts differ,” or “The weights tie, so the later declaration wins.” That sentence makes it possible to check whether the learner has used the correct stage of the cascade.
8. Keep inheritance separate from competing declarations
Some properties, including colour in ordinary circumstances, can be inherited from a parent. But a declaration that directly targets a child element is not competing on equal terms with the parent's inherited value. The child's own applicable declaration can supply its colour even when the parent selector has a high specificity.
Suppose #page gives a container a purple colour, while p gives its paragraph a black colour. The paragraph becomes black because its own declaration sets the property. The parent ID does not make inherited purple defeat a direct declaration on the paragraph.
This is a frequent misunderstanding because the selectors appear in the same stylesheet. The student compares the ID and the type selector without noticing that they target different elements. Specificity comparison must relate to declarations competing for the property on the same element.
Use the browser's computed-style view to separate the paragraph's winning declaration from inherited values. The learner should point to which element each selector matches. This simple habit can resolve an apparently complicated conflict.
The words inherit, initial, unset, revert and revert-layer have distinct meanings and should not be treated as interchangeable repairs. For this lesson, first establish the core difference between a declared value on the child and a value received through inheritance. Add the reset keywords only when the learner has a concrete reason to use them.
9. Understand inline styles without making them the normal repair
A normal inline style on an element has priority over normal author stylesheet declarations. For teaching purposes, it is often represented as an additional leading specificity column. But inline styles also have their own place in the cascade, so avoid reducing every case to a single three-column selector calculation.
If a paragraph has an inline green colour, a normal stylesheet class rule setting blue will not override it simply by adding more class selectors. The student should inspect the element for inline declarations, including styles added by scripts.
Inline styles can be appropriate in some generated interfaces, but they are rarely a helpful default answer to a beginner's conflict. They make the source of a value less centralised and can encourage a patch on every affected element instead of a clear stylesheet rule.
For an exercise, add an inline colour deliberately, inspect the resulting winner, then remove the inline declaration and observe the stylesheet competition again. The purpose is to identify where the value came from. Do not leave the experiment as an unexplained permanent patch in the final project.
A tutor can ask the student to name the location of the winning declaration: the element, a stylesheet, a layer or an inherited value. Knowing the location is often the first step towards a maintainable repair.
10. Treat important as an importance change
The annotation !important does not add IDs or classes to a selector. It marks a declaration as important, moving the comparison into a different importance category. Within that category, other cascade rules still matter. Describing important as “maximum specificity” is technically misleading.
For a small same-origin, same-layer example, an important type-selector declaration can defeat a normal class declaration. The reason is importance, not a higher selector tuple. This is why counting selectors alone does not explain every winning style.
.notice { color: green; }
p { color: blue !important; }The paragraph is blue under these conditions. Adding an ID to the normal notice rule would still not make its normal declaration win against that important author declaration. The student needs to identify the deciding stage rather than build an ever-longer selector.
There are legitimate uses for important, and user important styles can support accessibility preferences. A beginner's routine project repair should nevertheless start by locating the conflicting declarations and improving their organisation. Repeated important patches make the next conflict harder to reason about.
Animations, transitions and the ordering of origins add further cascade considerations. This guide's practice cases state their assumptions and do not claim that any important declaration defeats every possible value in every context.
11. Learn why cascade layers come before selector weight
Cascade layers let authors organise styles into ordered groups. For normal author declarations, later declared layers have priority over earlier layers. Normal unlayered author declarations have priority over normal declarations in named layers. These comparisons occur before specificity within the relevant layer.
This means a low-specificity selector in a higher-priority normal layer can defeat a high-specificity selector in a lower-priority layer. That is the point of layers: the stylesheet's intended organisation can govern priority without forcing every component to use heavier selectors.
@layer base, components;
@layer base {
#reading-page p { color: navy; }
}
@layer components {
.notice { color: green; }
}For a matching notice paragraph inside reading-page, green wins among these normal declarations. The components layer has higher priority than base. The ID in the base rule does not bypass the layer ordering.
A student who first learns layers through this tiny example can connect them to a real project later. They do not need to introduce layers into every first webpage. The immediate learning goal is to recognise why a seemingly heavier selector can lose correctly.
When inspecting a conflict, record the layer before counting selector columns. Otherwise, the learner may calculate the tuple perfectly and still answer the wrong question.
12. Know that important layer order reverses
Important declarations reverse the normal layer priority. Within an origin, important declarations in earlier layers take priority over those in later layers, and important layered declarations take priority over important unlayered declarations. This can surprise students who extend the normal-layer rule without checking importance.
Keep the first experiment simple. Use two named layers, one property and one element. Give both declarations important status. The rule in the earlier layer wins even if a normal version of the same experiment favoured the later layer.
The reversal serves the cascade's protection model; it is not random inconsistency. For a learner, the useful first step is to identify the separate ordering for important declarations and avoid applying the normal ordering automatically.
Do not turn this chapter into a reason to add important everywhere. The lesson is about explaining an existing stylesheet accurately. A maintainable project can often use normal declarations, a clear layer order and uncomplicated component selectors.
A strong explanation now has several parts: the declarations match, their origin is the same, both are important, their layers differ, and the earlier important layer decides the result. The learner has a sequence of checks rather than a vague belief that the “strongest-looking” selector must win.
13. Read is and not by their arguments
The functional pseudo-classes :is(), :not() and :has() do not contribute a fixed ordinary pseudo-class weight of their own. Their specificity is determined by the most specific selector in their argument list. This can make a selector heavier than its visible class branch suggests.
For example, :is(.notice, #special) has one-zero-zero specificity because the ID argument is the most specific. That weight applies when the selector matches through the notice branch as well. The browser does not choose a lower specificity just because that particular element matched the class alternative.
Similarly, p:not(.quiet) has zero-one-one: the class inside not supplies the middle contribution, and p supplies the type contribution. If an ID appears in not's selector list, it can raise the resulting weight.
Use argument lists deliberately. A student copying an ID alternative into is may accidentally raise the weight of every matching branch. When a future override becomes difficult, the hidden source of weight is the argument list.
For a teaching example, compare an is selector containing only classes with one containing a class and an ID. The matching elements can be similar, but the specificity changes. The learner should count the most specific argument, then add the remaining parts of the full selector.
14. Use where when a zero-weight wrapper is useful
The functional pseudo-class :where() has zero specificity, including its arguments. This makes it useful when you want to express a matching context without making that context harder to override. It is a selector-design tool, not a general command to remove the cascade.
Compare :is(#club) p and :where(#club) p. The first has an ID contribution plus a type contribution. The second has only the p type contribution because the where portion contributes zero.
:where(#club) p { color: navy; }
.notice { color: green; }For a notice paragraph inside club, the class rule wins specificity under equal cascade conditions. The contextual ID inside where does not add weight. This lets the base rule remain easy to override.
The student should also understand that zero weight does not mean no matching requirement. The paragraph still needs to be inside the club element for that contextual rule to match. Matching conditions and specificity remain separate ideas.
In a small educational project, where can help learners write base styles without accumulating unnecessary priority. But clarity comes first. If the functional syntax makes a first exercise harder to read, establish ordinary selectors before introducing the zero-weight wrapper.
15. Recognise nesting and selector-list surprises
Modern CSS nesting can make a nested rule's specificity depend on the parent selector list. If the parent list includes an ID selector, that can influence the nested selector's weight even when the element matches through another branch. This is related to the most-specific-argument behaviour of is.
A beginner reading a nested stylesheet should identify the full effective selector, not count only the text on the indented line. A nested p is not necessarily just a type selector in the final rule. Its context contributes to matching and can contribute to specificity.
When learning, first rewrite a small nested example as an explicit selector. This exposes what relationship is being expressed and which selectors supply the weight. Then compare with the nested form and discuss whether nesting improves readability for that project.
Do not rely on visual indentation as a complete explanation. The browser follows CSS syntax and cascade rules, not the student's sense that one line is “inside” another. Indentation supports human reading; the actual selectors determine behaviour.
For a first trial webpage, nesting is optional. Students can build clear, useful stylesheets without it. Knowing that it exists is most valuable when a learner encounters a project whose rules are not all written in flat form.
16. Use developer tools as evidence
Select the affected element in the browser's developer tools and inspect the styles for the property you are debugging. Matching declarations can appear with losing declarations crossed out. The computed view helps identify the resulting property value. The exact panel labels vary between browsers and versions.
Do not treat a crossed-out declaration as proof of lower specificity by itself. It may lose because of importance, layer order or another cascade stage. The panel gives evidence; the learner still needs to explain the reason.
A useful worksheet has five entries: the element, the property, the competing declaration locations, the selector weights where relevant, and the deciding cascade factor. This is short enough to use during a real project and specific enough to prevent random changes.
Also inspect states. A hover or focus rule may matter only when the relevant state is active. A student debugging only the resting state can miss the interaction rule that changes the result. Browser tools can help force or inspect states, depending on the browser.
For family practice, use a local imaginary project rather than editing a school's or organisation's live website. The learning objective is understanding the evidence. There is no need to change a real public page or publish the experiment.
17. Repair the conflict without escalating it
Once the winning rule is understood, choose a repair that fits the stylesheet's intended structure. Remove an obsolete rule, correct a class, move the appropriate rule within its layer, or introduce a clear modifier class. The best repair is the one whose reason remains understandable next week.
Suppose all notice elements are green, but a warning notice should be amber. Use a named modifier such as .notice.warning and define its purpose clearly. Do not append an arbitrary chain of ancestors just to win today's contest.
If a third-party stylesheet creates the conflict, consider a dedicated layer or a limited override with an explicit explanation. There may be constraints that make a targeted important declaration reasonable, but that decision should follow inspection, not reflex.
Avoid changing several properties and selectors at once. If the lesson concerns colour, keep the repair focused on colour. Otherwise, a successful refresh may conceal which change mattered and whether a new layout problem was introduced.
A tutor can assess understanding by asking the student to undo the repair and predict the old result, then reapply it and explain the new result. The learner is now controlling a known mechanism, rather than merely keeping the version that happened to look right.
18. Keep component selectors easy to override
A small project becomes easier to maintain when components use clear, modest selectors. A class such as notice can identify a component, while a modifier can represent a meaningful variation. Long ID-heavy chains often make later changes unnecessarily difficult.
This is not a rule that IDs must never appear in HTML. IDs are useful for unique fragment targets, labels and other relationships. The question is whether an ID is needed in a styling selector and what priority it introduces.
For a fictional Punggol reading-club page, the student can style card, title, notice and action classes. A warning modifier can change one notice without restyling every paragraph in the page. The example teaches scope of effect as well as selector weight.
Ask the learner to predict which elements will change before running the stylesheet. A technically winning rule that changes too many elements is not a good repair. Match coverage, cascade priority and reader-facing result all need attention.
The final stylesheet should communicate its intended roles. A parent may not understand every declaration, but a learner should be able to explain why the warning class exists and which part of the page it changes. That is a practical sign of organised thinking.
19. Protect keyboard and interaction styles
A visual repair should not unintentionally remove useful focus styling. If a student's new rule changes outlines or borders, check how the element appears when reached by keyboard as well as by pointer. A tidy screenshot alone does not reveal all relevant states.
Specificity can explain why a focus declaration loses, but the repair also needs a design purpose. A visible focus indicator helps a keyboard user know where interaction will occur. Do not remove it merely because the outline looks different from the resting button.
Use a genuine button or link in the practice page, then reach it with the keyboard. Compare the relevant focus declaration with the competing base and modifier rules. The learner can apply the same cascade reasoning to an interaction state that serves a real user need.
This is also an opportunity to distinguish appearance from semantics. CSS can style a div to look like a button, but styling alone does not supply native button behaviour. The specificity lesson should not encourage a visual imitation that creates avoidable interaction problems.
Keep the practical check modest: the notice colour changes as intended, the button remains readable, and keyboard focus stays visible. The student learns that a repaired declaration belongs inside a functioning interface.
20. Work through a specificity practice set
Assume normal author declarations in the same layer, no inline style and equal scoping proximity. Compare these pairs: .notice against p; #page against .card.notice; article .notice against .panel .notice; button.action against .action:hover; and :where(#page) p against .notice.
The class beats the type in the first pair. The ID wins the second pair because the leftmost column differs. In the third, the two-class selector wins against one class and one type. In the fourth, the two class-related contributions win against one class and one type. In the fifth, where contributes zero, so the ordinary class wins against the remaining type selector.
Now compare .panel p and .panel > p for a paragraph that is a direct child of panel. Their weights tie. The later applicable declaration wins under the stated assumptions. If the paragraph is not a direct child, the second selector does not match at all.
Finally, compare a normal declaration in an earlier layer with a normal declaration in a later layer. The later layer decides before specificity. Then mark both important and repeat: the important layer ordering reverses. The student should identify which stage changed.
Use one new example after each correction. A practice set should diagnose understanding, not reward a student for remembering the exact answer sequence printed here.
21. A manageable project for a Punggol learner
Build a small imaginary page with a heading, two reading cards, a notice and a button. Begin with type selectors, then introduce component classes. Add one intentional colour conflict and write a prediction before opening the page.
In a second session, add a modifier class to one notice. Ask the learner to explain the matching elements and the winning declaration. Keep the HTML short enough that the relationship between classes and elements remains visible.
In a third session, introduce a base layer and a component layer if the learner is ready. Reuse the same small page so the new concept is layer priority, not a simultaneous increase in project size. Record the reason the component declaration wins.
Around schoolwork, CCA and travel, a family can stop at a completed explanation rather than a fixed number of minutes. The learning milestone is observable: the student predicts a conflict, checks it, repairs it and explains the result. A larger page can wait.
If discussing support with a tutor, bring the HTML, the relevant CSS and a screenshot of the surprising state. “This paragraph should be green, but it is blue” is a precise starting point. “CSS does not work” is too broad to identify the next learning step.
22. Questions that help parents judge progress
Does my child need to memorise the whole cascade? A beginner should know that matching, importance, layers, specificity and source order are different checks. They can learn the finer details as the project requires them. The essential habit is to find the deciding factor rather than guess.
Is an ID always stronger than a class? In a specificity comparison, an ID contribution defeats a selector with no IDs. But the cascade includes stages before specificity, so an ID selector does not universally win against every declaration. The conditions must be stated.
Can adding important be correct? Sometimes. It should express an understood priority requirement, not conceal an unidentified conflict. A student who uses important should be able to explain which normal declaration it defeats and what future overrides will require.
Is the shortest selector always best? It depends on whether it matches the intended elements and fits the project structure. Readability and a controlled scope of effect matter. Shortness alone does not establish correctness.
What does mastery look like? Give the learner a new pair of rules, an element and clear cascade assumptions. They should predict the winner, explain the deciding stage and propose a repair that preserves other intended styles. That is stronger evidence than reproducing a finished example.
23. A debugging conversation that stays encouraging
When a page ignores a student's edit, begin with curiosity. Ask which element they expected to change, which property they changed and which rule they believe is winning. These questions make the problem smaller and observable without blaming the learner.
If the student cannot name the target, return to selector matching. If they can name the target but compare the wrong weights, return to the three columns. If the calculation is correct but the result is wrong, inspect importance, layers, inline declarations and inheritance.
Avoid praising a repair merely because the screenshot looks right. Ask whether a second notice still behaves correctly and whether interaction states remain visible. A local fix that breaks another component is useful evidence about scope, and it deserves a calm investigation.
The student's correction note can be one paragraph: “Both rules matched this paragraph. The component layer won before specificity. I moved the intended base rule into its correct layer and kept the notice class unchanged.” The note shows that the learner understands the mechanism and the design purpose.
This kind of conversation is practical for a busy Punggol family. It lets a parent support thinking without becoming the project's developer. The adult can ask for a clear explanation and leave the actual coding choices with the learner and their appropriate teacher or tutor.
24. Read the right reference for the next question
The MDN specificity guide provides the selector-counting rules and functional pseudo-class exceptions. The MDN cascade introduction explains the broader ordering that comes before and after specificity.
For layers, use MDN's cascade-layer lesson and the layer reference. For a zero-weight contextual selector, the where reference addresses that precise behaviour.
For a wider beginner project, the existing eduKate guide to HTML, CSS and JavaScript for a first website connects the styling question to the page's structure and behaviour. For the family learning arrangement, How Studying Works remains a useful Punggol route.
Keep the next step specific. If the learner can count selectors but cannot identify a matching element, practise matching. If they can explain ordinary rules but not a layered stylesheet, practise layers. The satisfying result is a page whose styles are understandable enough for the student to change deliberately.
25. Test a repair against a second element
A specificity repair is ready to keep when it solves the intended conflict and preserves the neighbouring elements that should stay different. Add a second paragraph without the notice class and a third paragraph with a different component class. Predict all three colours before refreshing. This checks the reach of the selector, not just whether it can overpower one declaration.
Suppose a student fixes a warning notice by changing every paragraph to amber. The warning now looks right, but the ordinary reading text changes as well. The repair has won a cascade contest while answering the wrong design question. A warning modifier is a more suitable expression of the intended difference when the project uses component classes.
Make the second test meaningfully different from the first. If the original failure happened in a direct-child paragraph, include a nested paragraph. If it happened in a focus state, also inspect the resting state. If it involved a layer, keep a base component whose normal appearance should remain controlled by that layer.
The student's final explanation should name both what changed and what remained intentionally different. For example: “The warning modifier sets the warning colour. The ordinary notice keeps its component colour, and body paragraphs keep the base colour.” That is a clearer account than “I made the selector stronger.”
Save the small test page with its prediction notes. When a later project creates a similar conflict, the student can compare mechanisms rather than copy a mysterious patch. The test becomes a compact example of controlled change: identify the target, explain the winner, repair the structure and check the nearby cases.
