When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
CSS :has() is a relational pseudo-class that matches an element when at least one relative selector in its argument matches when anchored against that element. It lets CSS style a parent, earlier sibling or component boundary according to related content or state. Mastery means reading the anchor correctly, controlling specificity with :is(), :where() and :not(), respecting the ban on nesting :has(), and keeping selectors local enough to remain understandable. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
E:has(rs) matches E when a relative selector in rs finds a match anchored against E. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling :has a selector that returns the descendant itself. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name the subject before reading the condition.
For the :has matches the anchor element chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling :has a selector that returns the descendant itself. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(.warning){border-color:crimson}Explained result. The card is styled when it contains a descendant matching .warning. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework checklist. Predict the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “E:has(rs) matches E when a relative selector in rs finds a match anchored against E.” Apply this procedure: Name the subject before reading the condition. The expected mechanism is: The card is styled when it contains a descendant matching .warning. For the homework checklist, add one near-miss that exposes calling :has a selector that returns the descendant itself. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Contrast the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “E:has(rs) matches E when a relative selector in rs finds a match anchored against E.” Apply this procedure: Name the subject before reading the condition. The expected mechanism is: The card is styled when it contains a descendant matching .warning. For the library catalogue, add one near-miss that exposes calling :has a selector that returns the descendant itself. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA form. Stress-test the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “E:has(rs) matches E when a relative selector in rs finds a match anchored against E.” Apply this procedure: Name the subject before reading the condition. The expected mechanism is: The card is styled when it contains a descendant matching .warning. For the CCA form, add one near-miss that exposes calling :has a selector that returns the descendant itself. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science gallery. Explain the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “E:has(rs) matches E when a relative selector in rs finds a match anchored against E.” Apply this procedure: Name the subject before reading the condition. The expected mechanism is: The card is styled when it contains a descendant matching .warning. For the science gallery, add one near-miss that exposes calling :has a selector that returns the descendant itself. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling :has a selector that returns the descendant itself.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Name the subject before reading the condition.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from :has matches the anchor element?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling :has a selector that returns the descendant itself be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with a row followed by an urgent row. Include one ordinary case, one boundary and one deliberate failure caused by calling :has a selector that returns the descendant itself. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: E:has(rs) matches E when a relative selector in rs finds a match anchored against E. It shows a trace, not only a final value. The ordinary case should demonstrate “The card is styled when it contains a descendant matching .warning.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Name the subject before reading the condition. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For :has matches the anchor element, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming only direct children are considered. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use > when direct-child structure is required.
For the A descendant condition is the default chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming only direct children are considered. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.list:has(.item.selected){background:mintcream}Explained result. The list matches when any descendant has both item and selected classes. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA form. Contrast the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor.” Apply this procedure: Use > when direct-child structure is required. The expected mechanism is: The list matches when any descendant has both item and selected classes. For the CCA form, add one near-miss that exposes assuming only direct children are considered. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science gallery. Stress-test the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor.” Apply this procedure: Use > when direct-child structure is required. The expected mechanism is: The list matches when any descendant has both item and selected classes. For the science gallery, add one near-miss that exposes assuming only direct children are considered. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Explain the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor.” Apply this procedure: Use > when direct-child structure is required. The expected mechanism is: The list matches when any descendant has both item and selected classes. For the revision dashboard, add one near-miss that exposes assuming only direct children are considered. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Transfer the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor.” Apply this procedure: Use > when direct-child structure is required. The expected mechanism is: The list matches when any descendant has both item and selected classes. For the family planner, add one near-miss that exposes assuming only direct children are considered. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming only direct children are considered.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use > when direct-child structure is required.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from A descendant condition is the default?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming only direct children are considered be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible component with labels and states already exposed in semantic HTML. Include one ordinary case, one boundary and one deliberate failure caused by assuming only direct children are considered. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor. It shows a trace, not only a final value. The ordinary case should demonstrate “The list matches when any descendant has both item and selected classes.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use > when direct-child structure is required. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A descendant condition is the default, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A leading > requires the matching element to be a direct child of the anchor. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is letting a deeply nested badge satisfy a component-level rule unintentionally. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw one direct and one nested fixture.
For the The child combinator narrows structure chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on letting a deeply nested badge satisfy a component-level rule unintentionally. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(> .badge){padding-block-start:2rem}Explained result. Only a card with a direct child .badge matches. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Stress-test the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading > requires the matching element to be a direct child of the anchor.” Apply this procedure: Draw one direct and one nested fixture. The expected mechanism is: Only a card with a direct child .badge matches. For the revision dashboard, add one near-miss that exposes letting a deeply nested badge satisfy a component-level rule unintentionally. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Explain the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading > requires the matching element to be a direct child of the anchor.” Apply this procedure: Draw one direct and one nested fixture. The expected mechanism is: Only a card with a direct child .badge matches. For the family planner, add one near-miss that exposes letting a deeply nested badge satisfy a component-level rule unintentionally. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible component. Transfer the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading > requires the matching element to be a direct child of the anchor.” Apply this procedure: Draw one direct and one nested fixture. The expected mechanism is: Only a card with a direct child .badge matches. For the accessible component, add one near-miss that exposes letting a deeply nested badge satisfy a component-level rule unintentionally. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: selector laboratory. Predict the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading > requires the matching element to be a direct child of the anchor.” Apply this procedure: Draw one direct and one nested fixture. The expected mechanism is: Only a card with a direct child .badge matches. For the selector laboratory, add one near-miss that exposes letting a deeply nested badge satisfy a component-level rule unintentionally. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers letting a deeply nested badge satisfy a component-level rule unintentionally.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Draw one direct and one nested fixture.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from The child combinator narrows structure?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing letting a deeply nested badge satisfy a component-level rule unintentionally be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny selector laboratory with small DOM fixtures with exact match assertions. Include one ordinary case, one boundary and one deliberate failure caused by letting a deeply nested badge satisfy a component-level rule unintentionally. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A leading > requires the matching element to be a direct child of the anchor. It shows a trace, not only a final value. The ordinary case should demonstrate “Only a card with a direct child .badge matches.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Draw one direct and one nested fixture. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For The child combinator narrows structure, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 4 OF 20 . Build the model
4. Adjacent sibling conditions can style an earlier element
A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is trying to select a previous sibling with an ordinary forward selector. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Anchor the element to style and describe the following-sibling condition.
For the Adjacent sibling conditions can style an earlier element chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to select a previous sibling with an ordinary forward selector. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
h2:has(+ p.note){margin-block-end:.25rem}Explained result. The h2 matches when the next sibling is a paragraph with class note. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible component. Explain the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour.” Apply this procedure: Anchor the element to style and describe the following-sibling condition. The expected mechanism is: The h2 matches when the next sibling is a paragraph with class note. For the accessible component, add one near-miss that exposes trying to select a previous sibling with an ordinary forward selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: selector laboratory. Transfer the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour.” Apply this procedure: Anchor the element to style and describe the following-sibling condition. The expected mechanism is: The h2 matches when the next sibling is a paragraph with class note. For the selector laboratory, add one near-miss that exposes trying to select a previous sibling with an ordinary forward selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework checklist. Predict the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour.” Apply this procedure: Anchor the element to style and describe the following-sibling condition. The expected mechanism is: The h2 matches when the next sibling is a paragraph with class note. For the homework checklist, add one near-miss that exposes trying to select a previous sibling with an ordinary forward selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Contrast the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour.” Apply this procedure: Anchor the element to style and describe the following-sibling condition. The expected mechanism is: The h2 matches when the next sibling is a paragraph with class note. For the library catalogue, add one near-miss that exposes trying to select a previous sibling with an ordinary forward selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers trying to select a previous sibling with an ordinary forward selector.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Anchor the element to style and describe the following-sibling condition.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Adjacent sibling conditions can style an earlier element?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to select a previous sibling with an ordinary forward selector be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework checklist with a card containing an unfinished checkbox. Include one ordinary case, one boundary and one deliberate failure caused by trying to select a previous sibling with an ordinary forward selector. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour. It shows a trace, not only a final value. The ordinary case should demonstrate “The h2 matches when the next sibling is a paragraph with class note.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Anchor the element to style and describe the following-sibling condition. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Adjacent sibling conditions can style an earlier element, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 5 OF 20 . Use the core tools
5. General sibling conditions look farther ahead
A leading ~ asks whether a matching later sibling exists after the anchor. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming the condition requires adjacency. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test an intervening element and an absent later match.
For the General sibling conditions look farther ahead chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the condition requires adjacency. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.step:has(~ .step.current){opacity:.65}Explained result. An earlier step matches when a later sibling step is current. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework checklist. Transfer the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading ~ asks whether a matching later sibling exists after the anchor.” Apply this procedure: Test an intervening element and an absent later match. The expected mechanism is: An earlier step matches when a later sibling step is current. For the homework checklist, add one near-miss that exposes assuming the condition requires adjacency. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Predict the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading ~ asks whether a matching later sibling exists after the anchor.” Apply this procedure: Test an intervening element and an absent later match. The expected mechanism is: An earlier step matches when a later sibling step is current. For the library catalogue, add one near-miss that exposes assuming the condition requires adjacency. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA form. Contrast the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading ~ asks whether a matching later sibling exists after the anchor.” Apply this procedure: Test an intervening element and an absent later match. The expected mechanism is: An earlier step matches when a later sibling step is current. For the CCA form, add one near-miss that exposes assuming the condition requires adjacency. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science gallery. Stress-test the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A leading ~ asks whether a matching later sibling exists after the anchor.” Apply this procedure: Test an intervening element and an absent later match. The expected mechanism is: An earlier step matches when a later sibling step is current. For the science gallery, add one near-miss that exposes assuming the condition requires adjacency. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming the condition requires adjacency.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test an intervening element and an absent later match.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from General sibling conditions look farther ahead?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the condition requires adjacency be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library catalogue with a result containing an available badge. Include one ordinary case, one boundary and one deliberate failure caused by assuming the condition requires adjacency. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A leading ~ asks whether a matching later sibling exists after the anchor. It shows a trace, not only a final value. The ordinary case should demonstrate “An earlier step matches when a later sibling step is current.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test an intervening element and an absent later match. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For General sibling conditions look farther ahead, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 6 OF 20 . Use the core tools
6. Commas express alternative relative selectors
:has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reading comma-separated branches as all required conditions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test each branch independently and together.
For the Commas express alternative relative selectors chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading comma-separated branches as all required conditions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(img,video){min-block-size:12rem}Explained result. The card matches when it contains an image or a video. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA form. Predict the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition.” Apply this procedure: Test each branch independently and together. The expected mechanism is: The card matches when it contains an image or a video. For the CCA form, add one near-miss that exposes reading comma-separated branches as all required conditions. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science gallery. Contrast the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition.” Apply this procedure: Test each branch independently and together. The expected mechanism is: The card matches when it contains an image or a video. For the science gallery, add one near-miss that exposes reading comma-separated branches as all required conditions. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Stress-test the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition.” Apply this procedure: Test each branch independently and together. The expected mechanism is: The card matches when it contains an image or a video. For the revision dashboard, add one near-miss that exposes reading comma-separated branches as all required conditions. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Explain the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition.” Apply this procedure: Test each branch independently and together. The expected mechanism is: The card matches when it contains an image or a video. For the family planner, add one near-miss that exposes reading comma-separated branches as all required conditions. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reading comma-separated branches as all required conditions.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Test each branch independently and together.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Commas express alternative relative selectors?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading comma-separated branches as all required conditions be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA form with a field group containing an invalid control. Include one ordinary case, one boundary and one deliberate failure caused by reading comma-separated branches as all required conditions. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: :has accepts a forgiving relative-selector list, so any valid matching branch can satisfy the condition. It shows a trace, not only a final value. The ordinary case should demonstrate “The card matches when it contains an image or a video.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Test each branch independently and together. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Commas express alternative relative selectors, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Two :has pseudo-classes in one compound selector must both match. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is placing conditions in one comma list and expecting AND. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate required conditions into separate :has calls.
For the Multiple :has clauses can express AND chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on placing conditions in one comma list and expecting AND. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(h2):has(.actions){display:grid}Explained result. The card needs both a descendant h2 and a descendant .actions element. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Contrast the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two :has pseudo-classes in one compound selector must both match.” Apply this procedure: Separate required conditions into separate :has calls. The expected mechanism is: The card needs both a descendant h2 and a descendant .actions element. For the revision dashboard, add one near-miss that exposes placing conditions in one comma list and expecting AND. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Stress-test the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two :has pseudo-classes in one compound selector must both match.” Apply this procedure: Separate required conditions into separate :has calls. The expected mechanism is: The card needs both a descendant h2 and a descendant .actions element. For the family planner, add one near-miss that exposes placing conditions in one comma list and expecting AND. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible component. Explain the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two :has pseudo-classes in one compound selector must both match.” Apply this procedure: Separate required conditions into separate :has calls. The expected mechanism is: The card needs both a descendant h2 and a descendant .actions element. For the accessible component, add one near-miss that exposes placing conditions in one comma list and expecting AND. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: selector laboratory. Transfer the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Two :has pseudo-classes in one compound selector must both match.” Apply this procedure: Separate required conditions into separate :has calls. The expected mechanism is: The card needs both a descendant h2 and a descendant .actions element. For the selector laboratory, add one near-miss that exposes placing conditions in one comma list and expecting AND. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers placing conditions in one comma list and expecting AND.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Separate required conditions into separate :has calls.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Multiple :has clauses can express AND?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing placing conditions in one comma list and expecting AND be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science gallery with a figure containing a selected thumbnail. Include one ordinary case, one boundary and one deliberate failure caused by placing conditions in one comma list and expecting AND. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Two :has pseudo-classes in one compound selector must both match. It shows a trace, not only a final value. The ordinary case should demonstrate “The card needs both a descendant h2 and a descendant .actions element.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Separate required conditions into separate :has calls. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Multiple :has clauses can express AND, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Selectors Level 4 does not allow :has inside :has unless a future specification defines it. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is writing :has(.group:has(.error)). It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Flatten the relationship or add a semantic class/state at an appropriate boundary.
For the :has cannot be nested chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing :has(.group:has(.error)). Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.page:has(.group .error){outline:2px solid}Explained result. The valid selector checks for an error inside a group without nesting :has. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible component. Stress-test the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors Level 4 does not allow :has inside :has unless a future specification defines it.” Apply this procedure: Flatten the relationship or add a semantic class/state at an appropriate boundary. The expected mechanism is: The valid selector checks for an error inside a group without nesting :has. For the accessible component, add one near-miss that exposes writing :has(.group:has(.error)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: selector laboratory. Explain the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors Level 4 does not allow :has inside :has unless a future specification defines it.” Apply this procedure: Flatten the relationship or add a semantic class/state at an appropriate boundary. The expected mechanism is: The valid selector checks for an error inside a group without nesting :has. For the selector laboratory, add one near-miss that exposes writing :has(.group:has(.error)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework checklist. Transfer the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors Level 4 does not allow :has inside :has unless a future specification defines it.” Apply this procedure: Flatten the relationship or add a semantic class/state at an appropriate boundary. The expected mechanism is: The valid selector checks for an error inside a group without nesting :has. For the homework checklist, add one near-miss that exposes writing :has(.group:has(.error)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Predict the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors Level 4 does not allow :has inside :has unless a future specification defines it.” Apply this procedure: Flatten the relationship or add a semantic class/state at an appropriate boundary. The expected mechanism is: The valid selector checks for an error inside a group without nesting :has. For the library catalogue, add one near-miss that exposes writing :has(.group:has(.error)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers writing :has(.group:has(.error)).
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Flatten the relationship or add a semantic class/state at an appropriate boundary.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from :has cannot be nested?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing :has(.group:has(.error)) be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision dashboard with a topic card containing strong progress. Include one ordinary case, one boundary and one deliberate failure caused by writing :has(.group:has(.error)). Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Selectors Level 4 does not allow :has inside :has unless a future specification defines it. It shows a trace, not only a final value. The ordinary case should demonstrate “The valid selector checks for an error inside a group without nesting :has.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Flatten the relationship or add a semantic class/state at an appropriate boundary. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For :has cannot be nested, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is trying to detect generated ::before content. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Put meaningful state in real markup or an attribute.
For the Pseudo-elements are generally excluded chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to detect generated ::before content. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has([data-status="ready"]){...}Explained result. The condition uses an explicit DOM state rather than generated content. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework checklist. Explain the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies.” Apply this procedure: Put meaningful state in real markup or an attribute. The expected mechanism is: The condition uses an explicit DOM state rather than generated content. For the homework checklist, add one near-miss that exposes trying to detect generated ::before content. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Transfer the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies.” Apply this procedure: Put meaningful state in real markup or an attribute. The expected mechanism is: The condition uses an explicit DOM state rather than generated content. For the library catalogue, add one near-miss that exposes trying to detect generated ::before content. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA form. Predict the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies.” Apply this procedure: Put meaningful state in real markup or an attribute. The expected mechanism is: The condition uses an explicit DOM state rather than generated content. For the CCA form, add one near-miss that exposes trying to detect generated ::before content. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science gallery. Contrast the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies.” Apply this procedure: Put meaningful state in real markup or an attribute. The expected mechanism is: The condition uses an explicit DOM state rather than generated content. For the science gallery, add one near-miss that exposes trying to detect generated ::before content. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers trying to detect generated ::before content.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Put meaningful state in real markup or an attribute.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Pseudo-elements are generally excluded?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to detect generated ::before content be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with a row followed by an urgent row. Include one ordinary case, one boundary and one deliberate failure caused by trying to detect generated ::before content. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Pseudo-elements are not valid inside :has unless explicitly designated as :has-allowed, avoiding cyclic style dependencies. It shows a trace, not only a final value. The ordinary case should demonstrate “The condition uses an explicit DOM state rather than generated content.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Put meaningful state in real markup or an attribute. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Pseudo-elements are generally excluded, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 10 OF 20 . Handle boundaries
10. Specificity comes from the most specific argument
:has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Calculate the argument maximum before comparing rules.
For the Specificity comes from the most specific argument chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(#urgent,.note){color:red}Explained result. The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA form. Transfer the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules.” Apply this procedure: Calculate the argument maximum before comparing rules. The expected mechanism is: The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. For the CCA form, add one near-miss that exposes counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science gallery. Predict the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules.” Apply this procedure: Calculate the argument maximum before comparing rules. The expected mechanism is: The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. For the science gallery, add one near-miss that exposes counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Contrast the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules.” Apply this procedure: Calculate the argument maximum before comparing rules. The expected mechanism is: The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. For the revision dashboard, add one near-miss that exposes counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Stress-test the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules.” Apply this procedure: Calculate the argument maximum before comparing rules. The expected mechanism is: The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. For the family planner, add one near-miss that exposes counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers counting :has itself as one ordinary pseudo-class and missing an ID in its arguments.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Calculate the argument maximum before comparing rules.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Specificity comes from the most specific argument?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing counting :has itself as one ordinary pseudo-class and missing an ID in its arguments be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible component with labels and states already exposed in semantic HTML. Include one ordinary case, one boundary and one deliberate failure caused by counting :has itself as one ordinary pseudo-class and missing an ID in its arguments. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: :has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules. It shows a trace, not only a final value. The ordinary case should demonstrate “The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Calculate the argument maximum before comparing rules. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Specificity comes from the most specific argument, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 11 OF 20 . Handle boundaries
11. :where can deliberately remove argument specificity
:where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using :has with a high-specificity branch and compensating with !important. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Design specificity instead of escalating it.
For the :where can deliberately remove argument specificity chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using :has with a high-specificity branch and compensating with !important. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(:where(#urgent,.note)){color:red}Explained result. The :where argument contributes zero specificity to the relational condition. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Predict the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly.” Apply this procedure: Design specificity instead of escalating it. The expected mechanism is: The :where argument contributes zero specificity to the relational condition. For the revision dashboard, add one near-miss that exposes using :has with a high-specificity branch and compensating with !important. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Contrast the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly.” Apply this procedure: Design specificity instead of escalating it. The expected mechanism is: The :where argument contributes zero specificity to the relational condition. For the family planner, add one near-miss that exposes using :has with a high-specificity branch and compensating with !important. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible component. Stress-test the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly.” Apply this procedure: Design specificity instead of escalating it. The expected mechanism is: The :where argument contributes zero specificity to the relational condition. For the accessible component, add one near-miss that exposes using :has with a high-specificity branch and compensating with !important. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: selector laboratory. Explain the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly.” Apply this procedure: Design specificity instead of escalating it. The expected mechanism is: The :where argument contributes zero specificity to the relational condition. For the selector laboratory, add one near-miss that exposes using :has with a high-specificity branch and compensating with !important. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using :has with a high-specificity branch and compensating with !important.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Design specificity instead of escalating it.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from :where can deliberately remove argument specificity?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using :has with a high-specificity branch and compensating with !important be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny selector laboratory with small DOM fixtures with exact match assertions. Include one ordinary case, one boundary and one deliberate failure caused by using :has with a high-specificity branch and compensating with !important. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: :where always contributes zero specificity, so wrapping a :has argument policy can keep component rules override-friendly. It shows a trace, not only a final value. The ordinary case should demonstrate “The :where argument contributes zero specificity to the relational condition.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Design specificity instead of escalating it. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For :where can deliberately remove argument specificity, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 12 OF 20 . Handle boundaries
12. :is groups alternatives with normal maximum specificity
:is can group selector alternatives inside the relationship while retaining the maximum specificity of its list. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is duplicating long selectors and letting versions drift. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use :is when grouped alternatives should affect specificity.
For the :is groups alternatives with normal maximum specificity chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on duplicating long selectors and letting versions drift. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.card:has(> :is(img,video,canvas)){...}Explained result. The card matches a direct child of any listed media type. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible component. Contrast the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:is can group selector alternatives inside the relationship while retaining the maximum specificity of its list.” Apply this procedure: Use :is when grouped alternatives should affect specificity. The expected mechanism is: The card matches a direct child of any listed media type. For the accessible component, add one near-miss that exposes duplicating long selectors and letting versions drift. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: selector laboratory. Stress-test the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:is can group selector alternatives inside the relationship while retaining the maximum specificity of its list.” Apply this procedure: Use :is when grouped alternatives should affect specificity. The expected mechanism is: The card matches a direct child of any listed media type. For the selector laboratory, add one near-miss that exposes duplicating long selectors and letting versions drift. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework checklist. Explain the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:is can group selector alternatives inside the relationship while retaining the maximum specificity of its list.” Apply this procedure: Use :is when grouped alternatives should affect specificity. The expected mechanism is: The card matches a direct child of any listed media type. For the homework checklist, add one near-miss that exposes duplicating long selectors and letting versions drift. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Transfer the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:is can group selector alternatives inside the relationship while retaining the maximum specificity of its list.” Apply this procedure: Use :is when grouped alternatives should affect specificity. The expected mechanism is: The card matches a direct child of any listed media type. For the library catalogue, add one near-miss that exposes duplicating long selectors and letting versions drift. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers duplicating long selectors and letting versions drift.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use :is when grouped alternatives should affect specificity.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from :is groups alternatives with normal maximum specificity?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing duplicating long selectors and letting versions drift be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework checklist with a card containing an unfinished checkbox. Include one ordinary case, one boundary and one deliberate failure caused by duplicating long selectors and letting versions drift. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: :is can group selector alternatives inside the relationship while retaining the maximum specificity of its list. It shows a trace, not only a final value. The ordinary case should demonstrate “The card matches a direct child of any listed media type.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use :is when grouped alternatives should affect specificity. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For :is groups alternatives with normal maximum specificity, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
:not can negate a condition, and combining it with :has requires attention to order and meaning. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is confusing section:not(:has(h1)) with section:has(:not(h1)). It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Translate each selector into a sentence before using it.
For the :not can express absence carefully chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on confusing section:not(:has(h1)) with section:has(:not(h1)). Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
section:not(:has(h2)){border-style:dashed}Explained result. The section matches only when it has no descendant h2. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework checklist. Stress-test the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:not can negate a condition, and combining it with :has requires attention to order and meaning.” Apply this procedure: Translate each selector into a sentence before using it. The expected mechanism is: The section matches only when it has no descendant h2. For the homework checklist, add one near-miss that exposes confusing section:not(:has(h1)) with section:has(:not(h1)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Explain the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:not can negate a condition, and combining it with :has requires attention to order and meaning.” Apply this procedure: Translate each selector into a sentence before using it. The expected mechanism is: The section matches only when it has no descendant h2. For the library catalogue, add one near-miss that exposes confusing section:not(:has(h1)) with section:has(:not(h1)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA form. Transfer the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:not can negate a condition, and combining it with :has requires attention to order and meaning.” Apply this procedure: Translate each selector into a sentence before using it. The expected mechanism is: The section matches only when it has no descendant h2. For the CCA form, add one near-miss that exposes confusing section:not(:has(h1)) with section:has(:not(h1)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science gallery. Predict the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “:not can negate a condition, and combining it with :has requires attention to order and meaning.” Apply this procedure: Translate each selector into a sentence before using it. The expected mechanism is: The section matches only when it has no descendant h2. For the science gallery, add one near-miss that exposes confusing section:not(:has(h1)) with section:has(:not(h1)). The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers confusing section:not(:has(h1)) with section:has(:not(h1)).
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Translate each selector into a sentence before using it.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from :not can express absence carefully?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing confusing section:not(:has(h1)) with section:has(:not(h1)) be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library catalogue with a result containing an available badge. Include one ordinary case, one boundary and one deliberate failure caused by confusing section:not(:has(h1)) with section:has(:not(h1)). Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: :not can negate a condition, and combining it with :has requires attention to order and meaning. It shows a trace, not only a final value. The ordinary case should demonstrate “The section matches only when it has no descendant h2.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Translate each selector into a sentence before using it. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For :not can express absence carefully, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 14 OF 20 . Debug and verify
14. Form groups can respond to descendant validity
A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using colour alone to communicate an invalid field. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Pair styling with labels, messages and valid semantic state.
For the Form groups can respond to descendant validity chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using colour alone to communicate an invalid field. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.field:has(input:invalid){border-color:crimson}Explained result. The field wrapper reflects its descendant input’s invalid state. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA form. Explain the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts.” Apply this procedure: Pair styling with labels, messages and valid semantic state. The expected mechanism is: The field wrapper reflects its descendant input’s invalid state. For the CCA form, add one near-miss that exposes using colour alone to communicate an invalid field. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science gallery. Transfer the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts.” Apply this procedure: Pair styling with labels, messages and valid semantic state. The expected mechanism is: The field wrapper reflects its descendant input’s invalid state. For the science gallery, add one near-miss that exposes using colour alone to communicate an invalid field. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Predict the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts.” Apply this procedure: Pair styling with labels, messages and valid semantic state. The expected mechanism is: The field wrapper reflects its descendant input’s invalid state. For the revision dashboard, add one near-miss that exposes using colour alone to communicate an invalid field. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Contrast the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts.” Apply this procedure: Pair styling with labels, messages and valid semantic state. The expected mechanism is: The field wrapper reflects its descendant input’s invalid state. For the family planner, add one near-miss that exposes using colour alone to communicate an invalid field. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using colour alone to communicate an invalid field.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Pair styling with labels, messages and valid semantic state.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Form groups can respond to descendant validity?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using colour alone to communicate an invalid field be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA form with a field group containing an invalid control. Include one ordinary case, one boundary and one deliberate failure caused by using colour alone to communicate an invalid field. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A field group can match when it contains an invalid, checked or focused control, but HTML validation and accessibility remain separate contracts. It shows a trace, not only a final value. The ordinary case should demonstrate “The field wrapper reflects its descendant input’s invalid state.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Pair styling with labels, messages and valid semantic state. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Form groups can respond to descendant validity, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is removing the control’s own focus outline after adding a parent glow. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep a clear focus indicator on the actual focused element.
For the Focus-visible can shape a component boundary chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on removing the control’s own focus outline after adding a parent glow. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.search:has(:focus-visible){box-shadow:0 0 0 3px Highlight}Explained result. The search wrapper gains context while the focused control should remain visibly identifiable. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Transfer the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state.” Apply this procedure: Keep a clear focus indicator on the actual focused element. The expected mechanism is: The search wrapper gains context while the focused control should remain visibly identifiable. For the revision dashboard, add one near-miss that exposes removing the control’s own focus outline after adding a parent glow. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Predict the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state.” Apply this procedure: Keep a clear focus indicator on the actual focused element. The expected mechanism is: The search wrapper gains context while the focused control should remain visibly identifiable. For the family planner, add one near-miss that exposes removing the control’s own focus outline after adding a parent glow. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible component. Contrast the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state.” Apply this procedure: Keep a clear focus indicator on the actual focused element. The expected mechanism is: The search wrapper gains context while the focused control should remain visibly identifiable. For the accessible component, add one near-miss that exposes removing the control’s own focus outline after adding a parent glow. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: selector laboratory. Stress-test the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state.” Apply this procedure: Keep a clear focus indicator on the actual focused element. The expected mechanism is: The search wrapper gains context while the focused control should remain visibly identifiable. For the selector laboratory, add one near-miss that exposes removing the control’s own focus outline after adding a parent glow. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers removing the control’s own focus outline after adding a parent glow.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep a clear focus indicator on the actual focused element.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Focus-visible can shape a component boundary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing removing the control’s own focus outline after adding a parent glow be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science gallery with a figure containing a selected thumbnail. Include one ordinary case, one boundary and one deliberate failure caused by removing the control’s own focus outline after adding a parent glow. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A component can receive a focus treatment when a descendant has keyboard-relevant focus-visible state. It shows a trace, not only a final value. The ordinary case should demonstrate “The search wrapper gains context while the focused control should remain visibly identifiable.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep a clear focus indicator on the actual focused element. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Focus-visible can shape a component boundary, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 16 OF 20 . Debug and verify
16. Checked controls can drive local presentation
A container can respond to an existing checked control without JavaScript for modest presentation changes. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using a hidden checkbox to build complex application state that lacks semantics. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep the control labelled and reserve JavaScript for behavioural state machines.
For the Checked controls can drive local presentation chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a hidden checkbox to build complex application state that lacks semantics. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.option:has(input:checked){background:#eef5ea}Explained result. The option wrapper reflects the checked state of its descendant control. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible component. Predict the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A container can respond to an existing checked control without JavaScript for modest presentation changes.” Apply this procedure: Keep the control labelled and reserve JavaScript for behavioural state machines. The expected mechanism is: The option wrapper reflects the checked state of its descendant control. For the accessible component, add one near-miss that exposes using a hidden checkbox to build complex application state that lacks semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: selector laboratory. Contrast the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A container can respond to an existing checked control without JavaScript for modest presentation changes.” Apply this procedure: Keep the control labelled and reserve JavaScript for behavioural state machines. The expected mechanism is: The option wrapper reflects the checked state of its descendant control. For the selector laboratory, add one near-miss that exposes using a hidden checkbox to build complex application state that lacks semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework checklist. Stress-test the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A container can respond to an existing checked control without JavaScript for modest presentation changes.” Apply this procedure: Keep the control labelled and reserve JavaScript for behavioural state machines. The expected mechanism is: The option wrapper reflects the checked state of its descendant control. For the homework checklist, add one near-miss that exposes using a hidden checkbox to build complex application state that lacks semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Explain the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A container can respond to an existing checked control without JavaScript for modest presentation changes.” Apply this procedure: Keep the control labelled and reserve JavaScript for behavioural state machines. The expected mechanism is: The option wrapper reflects the checked state of its descendant control. For the library catalogue, add one near-miss that exposes using a hidden checkbox to build complex application state that lacks semantics. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using a hidden checkbox to build complex application state that lacks semantics.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep the control labelled and reserve JavaScript for behavioural state machines.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Checked controls can drive local presentation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a hidden checkbox to build complex application state that lacks semantics be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision dashboard with a topic card containing strong progress. Include one ordinary case, one boundary and one deliberate failure caused by using a hidden checkbox to build complex application state that lacks semantics. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A container can respond to an existing checked control without JavaScript for modest presentation changes. It shows a trace, not only a final value. The ordinary case should demonstrate “The option wrapper reflects the checked state of its descendant control.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep the control labelled and reserve JavaScript for behavioural state machines. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Checked controls can drive local presentation, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 17 OF 20 . Transfer with judgment
17. Document-wide conditions need restraint
Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is putting every component state into a body-level relational selector. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Prefer the nearest stable component boundary.
For the Document-wide conditions need restraint chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on putting every component state into a body-level relational selector. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.filters:has(input:checked) .clear{visibility:visible}Explained result. The condition stays within the filters component instead of coupling the entire page. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework checklist. Contrast the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace.” Apply this procedure: Prefer the nearest stable component boundary. The expected mechanism is: The condition stays within the filters component instead of coupling the entire page. For the homework checklist, add one near-miss that exposes putting every component state into a body-level relational selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library catalogue. Stress-test the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace.” Apply this procedure: Prefer the nearest stable component boundary. The expected mechanism is: The condition stays within the filters component instead of coupling the entire page. For the library catalogue, add one near-miss that exposes putting every component state into a body-level relational selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA form. Explain the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace.” Apply this procedure: Prefer the nearest stable component boundary. The expected mechanism is: The condition stays within the filters component instead of coupling the entire page. For the CCA form, add one near-miss that exposes putting every component state into a body-level relational selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science gallery. Transfer the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace.” Apply this procedure: Prefer the nearest stable component boundary. The expected mechanism is: The condition stays within the filters component instead of coupling the entire page. For the science gallery, add one near-miss that exposes putting every component state into a body-level relational selector. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers putting every component state into a body-level relational selector.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Prefer the nearest stable component boundary.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Document-wide conditions need restraint?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing putting every component state into a body-level relational selector be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with a row followed by an urgent row. Include one ordinary case, one boundary and one deliberate failure caused by putting every component state into a body-level relational selector. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Selectors such as body:has(…) can coordinate page state but create wide coupling and make ownership hard to trace. It shows a trace, not only a final value. The ordinary case should demonstrate “The condition stays within the filters component instead of coupling the entire page.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Prefer the nearest stable component boundary. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Document-wide conditions need restraint, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
@supports selector(:has(*)) can guard enhancements while a readable base layout remains available. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is hiding essential content unless :has is supported. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Build the base experience first and add relational styling as enhancement.
For the Feature queries can provide a fallback chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on hiding essential content unless :has is supported. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
@supports selector(:has(*)){.card:has(img){display:grid}}Explained result. Supporting browsers receive the enhancement; the card remains usable without it. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA form. Stress-test the rule using a field group containing an invalid control. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “@supports selector(:has(*)) can guard enhancements while a readable base layout remains available.” Apply this procedure: Build the base experience first and add relational styling as enhancement. The expected mechanism is: Supporting browsers receive the enhancement; the card remains usable without it. For the CCA form, add one near-miss that exposes hiding essential content unless :has is supported. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science gallery. Explain the rule using a figure containing a selected thumbnail. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “@supports selector(:has(*)) can guard enhancements while a readable base layout remains available.” Apply this procedure: Build the base experience first and add relational styling as enhancement. The expected mechanism is: Supporting browsers receive the enhancement; the card remains usable without it. For the science gallery, add one near-miss that exposes hiding essential content unless :has is supported. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Transfer the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “@supports selector(:has(*)) can guard enhancements while a readable base layout remains available.” Apply this procedure: Build the base experience first and add relational styling as enhancement. The expected mechanism is: Supporting browsers receive the enhancement; the card remains usable without it. For the revision dashboard, add one near-miss that exposes hiding essential content unless :has is supported. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Predict the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “@supports selector(:has(*)) can guard enhancements while a readable base layout remains available.” Apply this procedure: Build the base experience first and add relational styling as enhancement. The expected mechanism is: Supporting browsers receive the enhancement; the card remains usable without it. For the family planner, add one near-miss that exposes hiding essential content unless :has is supported. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers hiding essential content unless :has is supported.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Build the base experience first and add relational styling as enhancement.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Feature queries can provide a fallback?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing hiding essential content unless :has is supported be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible component with labels and states already exposed in semantic HTML. Include one ordinary case, one boundary and one deliberate failure caused by hiding essential content unless :has is supported. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: @supports selector(:has(*)) can guard enhancements while a readable base layout remains available. It shows a trace, not only a final value. The ordinary case should demonstrate “Supporting browsers receive the enhancement; the card remains usable without it.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Build the base experience first and add relational styling as enhancement. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Feature queries can provide a fallback, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 19 OF 20 . Transfer with judgment
19. Performance follows selector breadth and mutation frequency
Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is writing *:has(.state) across a large dynamic page. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a narrow subject, local relationship and measured real-page test.
For the Performance follows selector breadth and mutation frequency chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing *:has(.state) across a large dynamic page. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
.task-list > li:has(> input:checked){...}Explained result. The selector limits candidates to direct task-list items and a direct child state. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Explain the rule using a topic card containing strong progress. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs.” Apply this procedure: Use a narrow subject, local relationship and measured real-page test. The expected mechanism is: The selector limits candidates to direct task-list items and a direct child state. For the revision dashboard, add one near-miss that exposes writing *:has(.state) across a large dynamic page. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Transfer the rule using a row followed by an urgent row. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs.” Apply this procedure: Use a narrow subject, local relationship and measured real-page test. The expected mechanism is: The selector limits candidates to direct task-list items and a direct child state. For the family planner, add one near-miss that exposes writing *:has(.state) across a large dynamic page. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible component. Predict the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs.” Apply this procedure: Use a narrow subject, local relationship and measured real-page test. The expected mechanism is: The selector limits candidates to direct task-list items and a direct child state. For the accessible component, add one near-miss that exposes writing *:has(.state) across a large dynamic page. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: selector laboratory. Contrast the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs.” Apply this procedure: Use a narrow subject, local relationship and measured real-page test. The expected mechanism is: The selector limits candidates to direct task-list items and a direct child state. For the selector laboratory, add one near-miss that exposes writing *:has(.state) across a large dynamic page. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers writing *:has(.state) across a large dynamic page.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use a narrow subject, local relationship and measured real-page test.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from Performance follows selector breadth and mutation frequency?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing *:has(.state) across a large dynamic page be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny selector laboratory with small DOM fixtures with exact match assertions. Include one ordinary case, one boundary and one deliberate failure caused by writing *:has(.state) across a large dynamic page. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs. It shows a trace, not only a final value. The ordinary case should demonstrate “The selector limits candidates to direct task-list items and a direct child state.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use a narrow subject, local relationship and measured real-page test. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Performance follows selector breadth and mutation frequency, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is checking one visual screenshot and declaring the selector correct. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Assert matched elements with querySelectorAll and inspect cascade winners.
For the A selector matrix proves understanding chapter on CSS :has(), use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on checking one visual screenshot and declaring the selector correct. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
document.querySelectorAll('.card:has(> .badge)').lengthExplained result. The count can be compared with a hand-labelled fixture before the selector reaches production. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible component. Transfer the rule using labels and states already exposed in semantic HTML. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures.” Apply this procedure: Assert matched elements with querySelectorAll and inspect cascade winners. The expected mechanism is: The count can be compared with a hand-labelled fixture before the selector reaches production. For the accessible component, add one near-miss that exposes checking one visual screenshot and declaring the selector correct. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: selector laboratory. Predict the rule using small DOM fixtures with exact match assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures.” Apply this procedure: Assert matched elements with querySelectorAll and inspect cascade winners. The expected mechanism is: The count can be compared with a hand-labelled fixture before the selector reaches production. For the selector laboratory, add one near-miss that exposes checking one visual screenshot and declaring the selector correct. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework checklist. Contrast the rule using a card containing an unfinished checkbox. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures.” Apply this procedure: Assert matched elements with querySelectorAll and inspect cascade winners. The expected mechanism is: The count can be compared with a hand-labelled fixture before the selector reaches production. For the homework checklist, add one near-miss that exposes checking one visual screenshot and declaring the selector correct. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library catalogue. Stress-test the rule using a result containing an available badge. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures.” Apply this procedure: Assert matched elements with querySelectorAll and inspect cascade winners. The expected mechanism is: The count can be compared with a hand-labelled fixture before the selector reaches production. For the library catalogue, add one near-miss that exposes checking one visual screenshot and declaring the selector correct. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers checking one visual screenshot and declaring the selector correct.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Assert matched elements with querySelectorAll and inspect cascade winners.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final CSS :has() syntax. For this chapter, useful prompts are: “What did you expect from A selector matrix proves understanding?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing checking one visual screenshot and declaring the selector correct be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework checklist with a card containing an unfinished checkbox. Include one ordinary case, one boundary and one deliberate failure caused by checking one visual screenshot and declaring the selector correct. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A complete test varies descendant, child, adjacent sibling, later sibling, absence, specificity and unsupported nesting in tiny fixtures. It shows a trace, not only a final value. The ordinary case should demonstrate “The count can be compared with a hand-labelled fixture before the selector reaches production.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Assert matched elements with querySelectorAll and inspect cascade winners. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A selector matrix proves understanding, separate the documented CSS :has() mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. homework checklist: model, boundary and recovery
Create a small homework checklist using a card containing an unfinished checkbox. Combine “:has matches the anchor element” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: E:has(rs) matches E when a relative selector in rs finds a match anchored against E. Apply: Name the subject before reading the condition. Verify: The card is styled when it contains a descendant matching .warning. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. library catalogue: model, boundary and recovery
Create a small library catalogue using a result containing an available badge. Combine “Adjacent sibling conditions can style an earlier element” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A leading + looks from the anchor to its immediately following sibling, allowing selection of a label or row before a known neighbour. Apply: Anchor the element to style and describe the following-sibling condition. Verify: The h2 matches when the next sibling is a paragraph with class note. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. CCA form: model, boundary and recovery
Create a small CCA form using a field group containing an invalid control. Combine “Multiple :has clauses can express AND” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Two :has pseudo-classes in one compound selector must both match. Apply: Separate required conditions into separate :has calls. Verify: The card needs both a descendant h2 and a descendant .actions element. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. science gallery: model, boundary and recovery
Create a small science gallery using a figure containing a selected thumbnail. Combine “Specificity comes from the most specific argument” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: :has adopts the specificity of the most specific complex selector in its argument list, like :is and :not under current rules. Apply: Calculate the argument maximum before comparing rules. Verify: The ID branch gives the :has contribution ID-level specificity even when the matched branch is .note. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. revision dashboard: model, boundary and recovery
Create a small revision dashboard using a topic card containing strong progress. Combine “:not can express absence carefully” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: :not can negate a condition, and combining it with :has requires attention to order and meaning. Apply: Translate each selector into a sentence before using it. Verify: The section matches only when it has no descendant h2. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. family planner: model, boundary and recovery
Create a small family planner using a row followed by an urgent row. Combine “Checked controls can drive local presentation” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A container can respond to an existing checked control without JavaScript for modest presentation changes. Apply: Keep the control labelled and reserve JavaScript for behavioural state machines. Verify: The option wrapper reflects the checked state of its descendant control. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. accessible component: model, boundary and recovery
Create a small accessible component using labels and states already exposed in semantic HTML. Combine “Performance follows selector breadth and mutation frequency” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Modern engines optimise :has, but broad anchors and expansive descendant searches can cost more in changing DOMs. Apply: Use a narrow subject, local relationship and measured real-page test. Verify: The selector limits candidates to direct task-list items and a direct child state. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. selector laboratory: model, boundary and recovery
Create a small selector laboratory using small DOM fixtures with exact match assertions. Combine “A descendant condition is the default” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A space at the start of a relative selector is implicit, so :has(.item) searches descendants of the anchor. Apply: Use > when direct-child structure is required. Verify: The list matches when any descendant has both item and selected classes. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.
