PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

A sticky lesson index can look identical before and after it becomes pinned, and a reading panel can show a “more below” cue after the reader has already reached the end. Scroll-state container queries let descendants respond to observable sticky, snapping and scrollability states—when the component and fallback are designed carefully.

Declare container-type: scroll-state on the relevant container, then query features such as stuck, snapped or scrollable with @container scroll-state(…). Style descendants rather than the query container itself, prefer logical edges when writing modes matter, name nested containers deliberately and retain a useful base experience because support and behaviour must be verified in the actual browser environment.

This guide treats CSS scroll-state() container queries as a reasoning skill. It begins with the governing model, moves through worked examples and diagnostic routes, and ends with transfer cases, practice with explained answers, parent decisions and FAQs. The examples are proposed home or lesson activities; they are not claims about a physical Punggol branch, school affiliation, timetable, class size, fee or guaranteed result.

For a Punggol family, the practical aim is simple: a learner should be able to use a short study block before schoolwork, after CCA, or during a weekend library session without needing a large project. Each chapter is designed so the smallest useful example can be completed, discussed and saved as a test fixture.

The official technical reference for this article is CSS Conditional Rules Level 5 scroll-state query specification. Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

If the immediate concern is “I can copy the syntax but I cannot explain the result”, use the first route. If a real project is already failing, use the diagnostic route. Parents can use the final route to decide whether more practice, a smaller prerequisite or a different example is needed. For the wider learning framework, see How Studying Works.

Start from the model: Chapters 1–4. Begin with Declare a scroll-state query container and continue in order to Use the logical block-start edge.

Diagnose a confusing result: Chapters 5–8. Begin with Allow perpendicular stuck edges together and continue in order to Query a snapped inline axis.

Build reliable examples: Chapters 9–12. Begin with Query remaining scrollability and continue in order to Combine conditions with and.

Transfer to real work: Chapters 13–16. Begin with Use or for alternative states and continue in order to Understand feature-based container selection.

Decide and teach: Chapters 17–20. Begin with Allow axes to use different containers and continue in order to Test support and accessibility.

Open the full 20-chapter index

1. 1. Declare a scroll-state query container
2. 2. Style a descendant of the container
3. 3. Query a sticky top state
4. 4. Use the logical block-start edge
5. 5. Allow perpendicular stuck edges together
6. 6. Reject opposite stuck edges on one axis
7. 7. Query a snapped vertical state
8. 8. Query a snapped inline axis
9. 9. Query remaining scrollability
10. 10. Use logical scrollability edges
11. 11. Name a query container
12. 12. Combine conditions with and
13. 13. Use or for alternative states
14. 14. Negate a state deliberately
15. 15. Combine size and scroll-state containment
16. 16. Understand feature-based container selection
17. 17. Allow axes to use different containers
18. 18. Account for snapshot updates
19. 19. Build a useful fallback first
20. 20. Test support and accessibility

CHAPTER 1 OF 20 · Back to contents

1. Declare a scroll-state query container

The short answer: Declare a scroll-state query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: An element becomes eligible for scroll-state queries when its container-type includes scroll-state.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “An element becomes eligible for scroll-state queries when its container-type includes scroll-state.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the declare a scroll-state query container example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.shell{container-type:scroll-state}.shell>.status{color:gray}

Expected result and reasoning. The declaration establishes scroll-state containment; it does not by itself change visual styling. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Writing an @container query without an eligible ancestor can make a correct condition appear broken. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which ancestor establishes the required container type?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for declare a scroll-state query container
• Variable to hold constant: the surrounding setup, so the comparison isolates declare a scroll-state query container.
• Variable to change: remove container-type and compare the query match
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For declare a scroll-state query container, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a sticky lesson index. Transfer declare a scroll-state query container into a sticky lesson index. Preserve the governing rule—An element becomes eligible for scroll-state queries when its container-type includes scroll-state.—while identifying what changes. Declare a scroll-state query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “An element becomes eligible for scroll-state queries when its container-type includes scroll-state.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a horizontal gallery. Transfer declare a scroll-state query container into a horizontal gallery. Preserve the governing rule—An element becomes eligible for scroll-state queries when its container-type includes scroll-state.—while identifying what changes. Declare a scroll-state query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “An element becomes eligible for scroll-state queries when its container-type includes scroll-state.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an accessibility review. Transfer declare a scroll-state query container into an accessibility review. Preserve the governing rule—An element becomes eligible for scroll-state queries when its container-type includes scroll-state.—while identifying what changes. Declare a scroll-state query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “An element becomes eligible for scroll-state queries when its container-type includes scroll-state.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support matrix. Transfer declare a scroll-state query container into a browser-support matrix. Preserve the governing rule—An element becomes eligible for scroll-state queries when its container-type includes scroll-state.—while identifying what changes. Declare a scroll-state query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “An element becomes eligible for scroll-state queries when its container-type includes scroll-state.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for declare a scroll-state query container, predict the result, then remove container-type and compare the query match. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The declaration establishes scroll-state containment; it does not by itself change visual styling. The contrast follows from this rule: An element becomes eligible for scroll-state queries when its container-type includes scroll-state. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for declare a scroll-state query container, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain declare a scroll-state query container, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Contents · Full contents · Next: Style a descendant of the container →

CHAPTER 2 OF 20 · Back to contents

2. Style a descendant of the container

The short answer: Style a descendant of the container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the style a descendant of the container example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.sticky{container-type:scroll-state}.sticky>.label{opacity:.7}@container scroll-state(stuck:top){.label{opacity:1}}

Expected result and reasoning. The descendant label can respond when the sticky container is stuck. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Targeting .sticky itself inside its own query creates a self-styling expectation the model does not provide. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Is the selected element inside the query container?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for style a descendant of the container
• Variable to hold constant: the surrounding setup, so the comparison isolates style a descendant of the container.
• Variable to change: wrap the visible content in a child element
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For style a descendant of the container, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading panel. Transfer style a descendant of the container into a reading panel. Preserve the governing rule—Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.—while identifying what changes. Style a descendant of the container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a timetable card. Transfer style a descendant of the container into a timetable card. Preserve the governing rule—Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.—while identifying what changes. Style a descendant of the container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a writing-mode test. Transfer style a descendant of the container into a writing-mode test. Preserve the governing rule—Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.—while identifying what changes. Style a descendant of the container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system component. Transfer style a descendant of the container into a design-system component. Preserve the governing rule—Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.—while identifying what changes. Style a descendant of the container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for style a descendant of the container, predict the result, then wrap the visible content in a child element. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The descendant label can respond when the sticky container is stuck. The contrast follows from this rule: Container-query rules select descendants; they cannot use a scroll-state query to style the query container itself. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for style a descendant of the container, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain style a descendant of the container, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Declare a scroll-state query container · Full contents · Next: Query a sticky top state →

CHAPTER 3 OF 20 · Back to contents

3. Query a sticky top state

The short answer: Query a sticky top state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the query a sticky top state example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.toc{position:sticky;top:0;container-type:scroll-state}.toc>strong{box-shadow:none}@container scroll-state(stuck:top){.toc>strong{box-shadow:0 2px 4px #0003}}

Expected result and reasoning. In supporting implementations the child gains the shadow while the container is stuck at the top. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. container-type alone cannot make a non-sticky element become stuck. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does positioning and scroll geometry create a sticky constraint?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for query a sticky top state
• Variable to hold constant: the surrounding setup, so the comparison isolates query a sticky top state.
• Variable to change: remove position:sticky and observe the state
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For query a sticky top state, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a horizontal gallery. Transfer query a sticky top state into a horizontal gallery. Preserve the governing rule—scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.—while identifying what changes. Query a sticky top state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an accessibility review. Transfer query a sticky top state into an accessibility review. Preserve the governing rule—scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.—while identifying what changes. Query a sticky top state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support matrix. Transfer query a sticky top state into a browser-support matrix. Preserve the governing rule—scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.—while identifying what changes. Query a sticky top state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a sticky lesson index. Transfer query a sticky top state into a sticky lesson index. Preserve the governing rule—scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.—while identifying what changes. Query a sticky top state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for query a sticky top state, predict the result, then remove position:sticky and observe the state. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. In supporting implementations the child gains the shadow while the container is stuck at the top. The contrast follows from this rule: scroll-state(stuck: top) is true when a sticky-positioned container is stuck to the top edge. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for query a sticky top state, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain query a sticky top state, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Style a descendant of the container · Full contents · Next: Use the logical block-start edge →

CHAPTER 4 OF 20 · Back to contents

4. Use the logical block-start edge

The short answer: Use the logical block-start edge is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: The stuck feature accepts logical edges such as block-start, which follow writing mode.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “The stuck feature accepts logical edges such as block-start, which follow writing mode.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the use the logical block-start edge example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.note{position:sticky;inset-block-start:0;container-type:scroll-state}@container scroll-state(stuck:block-start){.note>span{font-weight:700}}

Expected result and reasoning. The query expresses the start of the block axis rather than assuming physical top. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Replacing every logical edge with top can break vertical writing modes. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which writing mode defines block-start here?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for use the logical block-start edge
• Variable to hold constant: the surrounding setup, so the comparison isolates use the logical block-start edge.
• Variable to change: test horizontal-tb and vertical-rl
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For use the logical block-start edge, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a timetable card. Transfer use the logical block-start edge into a timetable card. Preserve the governing rule—The stuck feature accepts logical edges such as block-start, which follow writing mode.—while identifying what changes. Use the logical block-start edge is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The stuck feature accepts logical edges such as block-start, which follow writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a writing-mode test. Transfer use the logical block-start edge into a writing-mode test. Preserve the governing rule—The stuck feature accepts logical edges such as block-start, which follow writing mode.—while identifying what changes. Use the logical block-start edge is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The stuck feature accepts logical edges such as block-start, which follow writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system component. Transfer use the logical block-start edge into a design-system component. Preserve the governing rule—The stuck feature accepts logical edges such as block-start, which follow writing mode.—while identifying what changes. Use the logical block-start edge is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The stuck feature accepts logical edges such as block-start, which follow writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading panel. Transfer use the logical block-start edge into a reading panel. Preserve the governing rule—The stuck feature accepts logical edges such as block-start, which follow writing mode.—while identifying what changes. Use the logical block-start edge is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The stuck feature accepts logical edges such as block-start, which follow writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for use the logical block-start edge, predict the result, then test horizontal-tb and vertical-rl. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The query expresses the start of the block axis rather than assuming physical top. The contrast follows from this rule: The stuck feature accepts logical edges such as block-start, which follow writing mode. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for use the logical block-start edge, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain use the logical block-start edge, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Query a sticky top state · Full contents · Next: Allow perpendicular stuck edges together →

CHAPTER 5 OF 20 · Back to contents

5. Allow perpendicular stuck edges together

The short answer: Allow perpendicular stuck edges together is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: A sticky element can be stuck on one edge of each axis at the same time, such as top and left.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “A sticky element can be stuck on one edge of each axis at the same time, such as top and left.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the allow perpendicular stuck edges together example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.card{position:sticky;top:0;left:0;container-type:scroll-state}@container scroll-state(stuck:top) and scroll-state(stuck:left){.card>b{outline:2px solid}}

Expected result and reasoning. The combined condition can match when both independent axis constraints are active. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming only one stuck value can ever be true ignores the two axes. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Are the tested edges on different axes?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for allow perpendicular stuck edges together
• Variable to hold constant: the surrounding setup, so the comparison isolates allow perpendicular stuck edges together.
• Variable to change: compare top plus left with top plus bottom
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For allow perpendicular stuck edges together, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an accessibility review. Transfer allow perpendicular stuck edges together into an accessibility review. Preserve the governing rule—A sticky element can be stuck on one edge of each axis at the same time, such as top and left.—while identifying what changes. Allow perpendicular stuck edges together is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A sticky element can be stuck on one edge of each axis at the same time, such as top and left.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a browser-support matrix. Transfer allow perpendicular stuck edges together into a browser-support matrix. Preserve the governing rule—A sticky element can be stuck on one edge of each axis at the same time, such as top and left.—while identifying what changes. Allow perpendicular stuck edges together is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A sticky element can be stuck on one edge of each axis at the same time, such as top and left.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a sticky lesson index. Transfer allow perpendicular stuck edges together into a sticky lesson index. Preserve the governing rule—A sticky element can be stuck on one edge of each axis at the same time, such as top and left.—while identifying what changes. Allow perpendicular stuck edges together is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A sticky element can be stuck on one edge of each axis at the same time, such as top and left.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a horizontal gallery. Transfer allow perpendicular stuck edges together into a horizontal gallery. Preserve the governing rule—A sticky element can be stuck on one edge of each axis at the same time, such as top and left.—while identifying what changes. Allow perpendicular stuck edges together is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A sticky element can be stuck on one edge of each axis at the same time, such as top and left.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for allow perpendicular stuck edges together, predict the result, then compare top plus left with top plus bottom. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The combined condition can match when both independent axis constraints are active. The contrast follows from this rule: A sticky element can be stuck on one edge of each axis at the same time, such as top and left. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for allow perpendicular stuck edges together, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain allow perpendicular stuck edges together, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Use the logical block-start edge · Full contents · Next: Reject opposite stuck edges on one axis →

CHAPTER 6 OF 20 · Back to contents

6. Reject opposite stuck edges on one axis

The short answer: Reject opposite stuck edges on one axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the reject opposite stuck edges on one axis example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(stuck:top) and scroll-state(stuck:bottom){.flag{display:block}}

Expected result and reasoning. The conjunction is not a reachable sticky state under the specified model. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Designing essential UI around an impossible conjunction creates an untestable branch. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Do the requested edges oppose each other on one axis?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for reject opposite stuck edges on one axis
• Variable to hold constant: the surrounding setup, so the comparison isolates reject opposite stuck edges on one axis.
• Variable to change: change bottom to left and retest
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For reject opposite stuck edges on one axis, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a writing-mode test. Transfer reject opposite stuck edges on one axis into a writing-mode test. Preserve the governing rule—A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.—while identifying what changes. Reject opposite stuck edges on one axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a design-system component. Transfer reject opposite stuck edges on one axis into a design-system component. Preserve the governing rule—A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.—while identifying what changes. Reject opposite stuck edges on one axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reading panel. Transfer reject opposite stuck edges on one axis into a reading panel. Preserve the governing rule—A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.—while identifying what changes. Reject opposite stuck edges on one axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a timetable card. Transfer reject opposite stuck edges on one axis into a timetable card. Preserve the governing rule—A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.—while identifying what changes. Reject opposite stuck edges on one axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for reject opposite stuck edges on one axis, predict the result, then change bottom to left and retest. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The conjunction is not a reachable sticky state under the specified model. The contrast follows from this rule: A scroll-state container cannot simultaneously be stuck to both opposing edges of the same axis. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for reject opposite stuck edges on one axis, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain reject opposite stuck edges on one axis, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Allow perpendicular stuck edges together · Full contents · Next: Query a snapped vertical state →

CHAPTER 7 OF 20 · Back to contents

7. Query a snapped vertical state

The short answer: Query a snapped vertical state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the query a snapped vertical state example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.slide{scroll-snap-align:start;container-type:scroll-state}@container scroll-state(snapped:y){.slide>.dot{background:green}}

Expected result and reasoning. The descendant indicator can reflect the snapped state in supporting implementations. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Adding scroll-snap-align without configuring a snapping scroll container may never establish the state. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which ancestor supplies scroll-snap-type and overflow?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for query a snapped vertical state
• Variable to hold constant: the surrounding setup, so the comparison isolates query a snapped vertical state.
• Variable to change: remove scroll-snap-type from the scroller
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For query a snapped vertical state, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a browser-support matrix. Transfer query a snapped vertical state into a browser-support matrix. Preserve the governing rule—scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.—while identifying what changes. Query a snapped vertical state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a sticky lesson index. Transfer query a snapped vertical state into a sticky lesson index. Preserve the governing rule—scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.—while identifying what changes. Query a snapped vertical state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a horizontal gallery. Transfer query a snapped vertical state into a horizontal gallery. Preserve the governing rule—scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.—while identifying what changes. Query a snapped vertical state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an accessibility review. Transfer query a snapped vertical state into an accessibility review. Preserve the governing rule—scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.—while identifying what changes. Query a snapped vertical state is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for query a snapped vertical state, predict the result, then remove scroll-snap-type from the scroller. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The descendant indicator can reflect the snapped state in supporting implementations. The contrast follows from this rule: scroll-state(snapped: y) tests whether a scroll-snap target container is snapped on the y axis. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for query a snapped vertical state, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain query a snapped vertical state, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Reject opposite stuck edges on one axis · Full contents · Next: Query a snapped inline axis →

CHAPTER 8 OF 20 · Back to contents

8. Query a snapped inline axis

The short answer: Query a snapped inline axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Logical axis values such as inline can make a snapping component adapt to writing mode.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Logical axis values such as inline can make a snapping component adapt to writing mode.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the query a snapped inline axis example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(snapped:inline){.panel>.marker{scale:1.2}}

Expected result and reasoning. The condition follows the container’s inline axis rather than hard-coding x. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating inline as always horizontal fails in vertical writing. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What is the inline axis in this writing mode?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for query a snapped inline axis
• Variable to hold constant: the surrounding setup, so the comparison isolates query a snapped inline axis.
• Variable to change: switch writing-mode and preserve logical intent
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For query a snapped inline axis, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a design-system component. Transfer query a snapped inline axis into a design-system component. Preserve the governing rule—Logical axis values such as inline can make a snapping component adapt to writing mode.—while identifying what changes. Query a snapped inline axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Logical axis values such as inline can make a snapping component adapt to writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reading panel. Transfer query a snapped inline axis into a reading panel. Preserve the governing rule—Logical axis values such as inline can make a snapping component adapt to writing mode.—while identifying what changes. Query a snapped inline axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Logical axis values such as inline can make a snapping component adapt to writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a timetable card. Transfer query a snapped inline axis into a timetable card. Preserve the governing rule—Logical axis values such as inline can make a snapping component adapt to writing mode.—while identifying what changes. Query a snapped inline axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Logical axis values such as inline can make a snapping component adapt to writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a writing-mode test. Transfer query a snapped inline axis into a writing-mode test. Preserve the governing rule—Logical axis values such as inline can make a snapping component adapt to writing mode.—while identifying what changes. Query a snapped inline axis is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Logical axis values such as inline can make a snapping component adapt to writing mode.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for query a snapped inline axis, predict the result, then switch writing-mode and preserve logical intent. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The condition follows the container’s inline axis rather than hard-coding x. The contrast follows from this rule: Logical axis values such as inline can make a snapping component adapt to writing mode. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for query a snapped inline axis, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain query a snapped inline axis, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Query a snapped vertical state · Full contents · Next: Query remaining scrollability →

CHAPTER 9 OF 20 · Back to contents

9. Query remaining scrollability

The short answer: Query remaining scrollability is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the query remaining scrollability example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.pane{overflow:auto;container-type:scroll-state}@container scroll-state(scrollable:bottom){.pane>.more{visibility:visible}}

Expected result and reasoning. The child hint can remain visible while more content exists below. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A tall descendant alone is insufficient if the container does not establish scrolling overflow. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Does the container have a scrollable box and remaining range?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for query remaining scrollability
• Variable to hold constant: the surrounding setup, so the comparison isolates query remaining scrollability.
• Variable to change: scroll to the end and observe the condition change
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For query remaining scrollability, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a sticky lesson index. Transfer query remaining scrollability into a sticky lesson index. Preserve the governing rule—scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.—while identifying what changes. Query remaining scrollability is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a horizontal gallery. Transfer query remaining scrollability into a horizontal gallery. Preserve the governing rule—scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.—while identifying what changes. Query remaining scrollability is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an accessibility review. Transfer query remaining scrollability into an accessibility review. Preserve the governing rule—scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.—while identifying what changes. Query remaining scrollability is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support matrix. Transfer query remaining scrollability into a browser-support matrix. Preserve the governing rule—scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.—while identifying what changes. Query remaining scrollability is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for query remaining scrollability, predict the result, then scroll to the end and observe the condition change. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The child hint can remain visible while more content exists below. The contrast follows from this rule: scroll-state(scrollable: bottom) is true when the query container’s scrolling box can be scrolled toward the bottom. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for query remaining scrollability, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain query remaining scrollability, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Query a snapped inline axis · Full contents · Next: Use logical scrollability edges →

CHAPTER 10 OF 20 · Back to contents

10. Use logical scrollability edges

The short answer: Use logical scrollability edges is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: block-end and inline-end express remaining scroll direction without fixing a physical orientation.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “block-end and inline-end express remaining scroll direction without fixing a physical orientation.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the use logical scrollability edges example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(scrollable:block-end){.reader>.cue{opacity:1}}

Expected result and reasoning. The cue follows the block flow in the active writing mode. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming bottom is always the reading direction encodes a locale-specific layout. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which logical edge represents later content?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for use logical scrollability edges
• Variable to hold constant: the surrounding setup, so the comparison isolates use logical scrollability edges.
• Variable to change: test right-to-left and vertical writing fixtures
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For use logical scrollability edges, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading panel. Transfer use logical scrollability edges into a reading panel. Preserve the governing rule—block-end and inline-end express remaining scroll direction without fixing a physical orientation.—while identifying what changes. Use logical scrollability edges is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “block-end and inline-end express remaining scroll direction without fixing a physical orientation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a timetable card. Transfer use logical scrollability edges into a timetable card. Preserve the governing rule—block-end and inline-end express remaining scroll direction without fixing a physical orientation.—while identifying what changes. Use logical scrollability edges is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “block-end and inline-end express remaining scroll direction without fixing a physical orientation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a writing-mode test. Transfer use logical scrollability edges into a writing-mode test. Preserve the governing rule—block-end and inline-end express remaining scroll direction without fixing a physical orientation.—while identifying what changes. Use logical scrollability edges is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “block-end and inline-end express remaining scroll direction without fixing a physical orientation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system component. Transfer use logical scrollability edges into a design-system component. Preserve the governing rule—block-end and inline-end express remaining scroll direction without fixing a physical orientation.—while identifying what changes. Use logical scrollability edges is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “block-end and inline-end express remaining scroll direction without fixing a physical orientation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for use logical scrollability edges, predict the result, then test right-to-left and vertical writing fixtures. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The cue follows the block flow in the active writing mode. The contrast follows from this rule: block-end and inline-end express remaining scroll direction without fixing a physical orientation. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for use logical scrollability edges, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain use logical scrollability edges, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Query remaining scrollability · Full contents · Next: Name a query container →

CHAPTER 11 OF 20 · Back to contents

11. Name a query container

The short answer: Name a query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: container-name lets a query select the intended scroll-state ancestor when several containers are nested.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “container-name lets a query select the intended scroll-state ancestor when several containers are nested.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the name a query container example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.chapter{container:chapter / scroll-state}@container chapter scroll-state(stuck:block-start){.title{background:Canvas}}

Expected result and reasoning. The named query considers the eligible ancestor named chapter. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Leaving a complex component unnamed may select a nearer eligible container than the author intended. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which ancestor has both the name and required feature type?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for name a query container
• Variable to hold constant: the surrounding setup, so the comparison isolates name a query container.
• Variable to change: add a nested unnamed container and verify selection
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For name a query container, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a horizontal gallery. Transfer name a query container into a horizontal gallery. Preserve the governing rule—container-name lets a query select the intended scroll-state ancestor when several containers are nested.—while identifying what changes. Name a query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “container-name lets a query select the intended scroll-state ancestor when several containers are nested.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an accessibility review. Transfer name a query container into an accessibility review. Preserve the governing rule—container-name lets a query select the intended scroll-state ancestor when several containers are nested.—while identifying what changes. Name a query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “container-name lets a query select the intended scroll-state ancestor when several containers are nested.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support matrix. Transfer name a query container into a browser-support matrix. Preserve the governing rule—container-name lets a query select the intended scroll-state ancestor when several containers are nested.—while identifying what changes. Name a query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “container-name lets a query select the intended scroll-state ancestor when several containers are nested.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a sticky lesson index. Transfer name a query container into a sticky lesson index. Preserve the governing rule—container-name lets a query select the intended scroll-state ancestor when several containers are nested.—while identifying what changes. Name a query container is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “container-name lets a query select the intended scroll-state ancestor when several containers are nested.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for name a query container, predict the result, then add a nested unnamed container and verify selection. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The named query considers the eligible ancestor named chapter. The contrast follows from this rule: container-name lets a query select the intended scroll-state ancestor when several containers are nested. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for name a query container, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain name a query container, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Use logical scrollability edges · Full contents · Next: Combine conditions with and →

CHAPTER 12 OF 20 · Back to contents

12. Combine conditions with and

The short answer: Combine conditions with and is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Scroll-state features can be combined with Boolean condition syntax when every fact must hold.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Scroll-state features can be combined with Boolean condition syntax when every fact must hold.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the combine conditions with and example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(stuck:top) and scroll-state(scrollable:bottom){.summary{border-color:green}}

Expected result and reasoning. The descendant style applies only when both states are true. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Comma-separated assumptions or duplicated rules may accidentally mean either condition rather than both. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Must one condition or all conditions hold?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for combine conditions with and
• Variable to hold constant: the surrounding setup, so the comparison isolates combine conditions with and.
• Variable to change: replace and with or and describe the expanded match set
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For combine conditions with and, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a timetable card. Transfer combine conditions with and into a timetable card. Preserve the governing rule—Scroll-state features can be combined with Boolean condition syntax when every fact must hold.—while identifying what changes. Combine conditions with and is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state features can be combined with Boolean condition syntax when every fact must hold.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a writing-mode test. Transfer combine conditions with and into a writing-mode test. Preserve the governing rule—Scroll-state features can be combined with Boolean condition syntax when every fact must hold.—while identifying what changes. Combine conditions with and is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state features can be combined with Boolean condition syntax when every fact must hold.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system component. Transfer combine conditions with and into a design-system component. Preserve the governing rule—Scroll-state features can be combined with Boolean condition syntax when every fact must hold.—while identifying what changes. Combine conditions with and is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state features can be combined with Boolean condition syntax when every fact must hold.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading panel. Transfer combine conditions with and into a reading panel. Preserve the governing rule—Scroll-state features can be combined with Boolean condition syntax when every fact must hold.—while identifying what changes. Combine conditions with and is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state features can be combined with Boolean condition syntax when every fact must hold.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for combine conditions with and, predict the result, then replace and with or and describe the expanded match set. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The descendant style applies only when both states are true. The contrast follows from this rule: Scroll-state features can be combined with Boolean condition syntax when every fact must hold. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for combine conditions with and, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain combine conditions with and, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Name a query container · Full contents · Next: Use or for alternative states →

CHAPTER 13 OF 20 · Back to contents

13. Use or for alternative states

The short answer: Use or for alternative states is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: The or operator matches when either of its scroll-state conditions is true.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “The or operator matches when either of its scroll-state conditions is true.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the use or for alternative states example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(stuck:top) or scroll-state(snapped:y){.badge{opacity:1}}

Expected result and reasoning. The badge can appear for either qualifying state. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using or when two simultaneous signals are required makes the UI overly eager. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Would either state independently justify the style?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for use or for alternative states
• Variable to hold constant: the surrounding setup, so the comparison isolates use or for alternative states.
• Variable to change: change to and and construct both geometries
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For use or for alternative states, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: an accessibility review. Transfer use or for alternative states into an accessibility review. Preserve the governing rule—The or operator matches when either of its scroll-state conditions is true.—while identifying what changes. Use or for alternative states is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The or operator matches when either of its scroll-state conditions is true.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a browser-support matrix. Transfer use or for alternative states into a browser-support matrix. Preserve the governing rule—The or operator matches when either of its scroll-state conditions is true.—while identifying what changes. Use or for alternative states is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The or operator matches when either of its scroll-state conditions is true.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a sticky lesson index. Transfer use or for alternative states into a sticky lesson index. Preserve the governing rule—The or operator matches when either of its scroll-state conditions is true.—while identifying what changes. Use or for alternative states is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The or operator matches when either of its scroll-state conditions is true.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a horizontal gallery. Transfer use or for alternative states into a horizontal gallery. Preserve the governing rule—The or operator matches when either of its scroll-state conditions is true.—while identifying what changes. Use or for alternative states is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The or operator matches when either of its scroll-state conditions is true.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for use or for alternative states, predict the result, then change to and and construct both geometries. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The badge can appear for either qualifying state. The contrast follows from this rule: The or operator matches when either of its scroll-state conditions is true. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for use or for alternative states, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain use or for alternative states, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Combine conditions with and · Full contents · Next: Negate a state deliberately →

CHAPTER 14 OF 20 · Back to contents

14. Negate a state deliberately

The short answer: Negate a state deliberately is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the negate a state deliberately example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container not scroll-state(scrollable:bottom){.end{font-weight:700}}

Expected result and reasoning. The end marker can be emphasised when no downward scroll range remains. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using a negated advanced query as the only readable state leaves unsupported browsers without the intended base experience. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “What useful base style exists when the query is unsupported?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for negate a state deliberately
• Variable to hold constant: the surrounding setup, so the comparison isolates negate a state deliberately.
• Variable to change: write the default first, then enhance the matched state
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For negate a state deliberately, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a writing-mode test. Transfer negate a state deliberately into a writing-mode test. Preserve the governing rule—The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.—while identifying what changes. Negate a state deliberately is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a design-system component. Transfer negate a state deliberately into a design-system component. Preserve the governing rule—The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.—while identifying what changes. Negate a state deliberately is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reading panel. Transfer negate a state deliberately into a reading panel. Preserve the governing rule—The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.—while identifying what changes. Negate a state deliberately is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a timetable card. Transfer negate a state deliberately into a timetable card. Preserve the governing rule—The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.—while identifying what changes. Negate a state deliberately is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for negate a state deliberately, predict the result, then write the default first, then enhance the matched state. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The end marker can be emphasised when no downward scroll range remains. The contrast follows from this rule: The not operator can express the absence of a specific scroll-state condition, but base styles are often clearer for fallback. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for negate a state deliberately, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain negate a state deliberately, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Use or for alternative states · Full contents · Next: Combine size and scroll-state containment →

CHAPTER 15 OF 20 · Back to contents

15. Combine size and scroll-state containment

The short answer: Combine size and scroll-state containment is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the combine size and scroll-state containment example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.panel{container-type:inline-size scroll-state}@container (width>30rem) and scroll-state(stuck:top){.panel>header{padding:1rem}}

Expected result and reasoning. The eligible container can supply the requested size and scroll-state features. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Adding containment types casually can affect layout and select a different query container. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which exact features does this component query?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for combine size and scroll-state containment
• Variable to hold constant: the surrounding setup, so the comparison isolates combine size and scroll-state containment.
• Variable to change: remove the unused type and retest container selection
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For combine size and scroll-state containment, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a browser-support matrix. Transfer combine size and scroll-state containment into a browser-support matrix. Preserve the governing rule—A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.—while identifying what changes. Combine size and scroll-state containment is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a sticky lesson index. Transfer combine size and scroll-state containment into a sticky lesson index. Preserve the governing rule—A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.—while identifying what changes. Combine size and scroll-state containment is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a horizontal gallery. Transfer combine size and scroll-state containment into a horizontal gallery. Preserve the governing rule—A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.—while identifying what changes. Combine size and scroll-state containment is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an accessibility review. Transfer combine size and scroll-state containment into an accessibility review. Preserve the governing rule—A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.—while identifying what changes. Combine size and scroll-state containment is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for combine size and scroll-state containment, predict the result, then remove the unused type and retest container selection. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The eligible container can supply the requested size and scroll-state features. The contrast follows from this rule: A container-type value can include both size-query and scroll-state capabilities where the component genuinely needs them. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for combine size and scroll-state containment, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain combine size and scroll-state containment, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Negate a state deliberately · Full contents · Next: Understand feature-based container selection →

CHAPTER 16 OF 20 · Back to contents

16. Understand feature-based container selection

The short answer: Understand feature-based container selection is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the understand feature-based container selection example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.outer{container-type:inline-size scroll-state}.inner{container-type:inline-size}@container (width>20rem) and scroll-state(stuck:top){.item{color:green}}

Expected result and reasoning. The inner container cannot satisfy the scroll-state feature, so selection must continue to a qualifying ancestor. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming the nearest size container always supplies a mixed query produces confusing results. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which ancestor supports all requested feature types?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for understand feature-based container selection
• Variable to hold constant: the surrounding setup, so the comparison isolates understand feature-based container selection.
• Variable to change: remove the scroll-state clause and compare the selected ancestor
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For understand feature-based container selection, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a design-system component. Transfer understand feature-based container selection into a design-system component. Preserve the governing rule—The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.—while identifying what changes. Understand feature-based container selection is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reading panel. Transfer understand feature-based container selection into a reading panel. Preserve the governing rule—The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.—while identifying what changes. Understand feature-based container selection is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a timetable card. Transfer understand feature-based container selection into a timetable card. Preserve the governing rule—The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.—while identifying what changes. Understand feature-based container selection is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a writing-mode test. Transfer understand feature-based container selection into a writing-mode test. Preserve the governing rule—The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.—while identifying what changes. Understand feature-based container selection is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for understand feature-based container selection, predict the result, then remove the scroll-state clause and compare the selected ancestor. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The inner container cannot satisfy the scroll-state feature, so selection must continue to a qualifying ancestor. The contrast follows from this rule: The query chooses an ancestor capable of every feature used; adding a feature can therefore change which ancestor is selected. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for understand feature-based container selection, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain understand feature-based container selection, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Combine size and scroll-state containment · Full contents · Next: Allow axes to use different containers →

CHAPTER 17 OF 20 · Back to contents

17. Allow axes to use different containers

The short answer: Allow axes to use different containers is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the allow axes to use different containers example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.outer{container-type:size scroll-state}.inner{container-type:inline-size}.item{display:block}

Expected result and reasoning. A careful test should record which ancestor supplies each requested capability rather than guessing from DOM distance. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Flattening all feature resolution into one nearest container can misdiagnose nested layouts. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which feature, axis and eligible ancestor are involved?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for allow axes to use different containers
• Variable to hold constant: the surrounding setup, so the comparison isolates allow axes to use different containers.
• Variable to change: simplify to one axis, then add the second condition
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For allow axes to use different containers, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a sticky lesson index. Transfer allow axes to use different containers into a sticky lesson index. Preserve the governing rule—Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.—while identifying what changes. Allow axes to use different containers is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a horizontal gallery. Transfer allow axes to use different containers into a horizontal gallery. Preserve the governing rule—Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.—while identifying what changes. Allow axes to use different containers is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an accessibility review. Transfer allow axes to use different containers into an accessibility review. Preserve the governing rule—Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.—while identifying what changes. Allow axes to use different containers is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a browser-support matrix. Transfer allow axes to use different containers into a browser-support matrix. Preserve the governing rule—Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.—while identifying what changes. Allow axes to use different containers is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for allow axes to use different containers, predict the result, then simplify to one axis, then add the second condition. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A careful test should record which ancestor supplies each requested capability rather than guessing from DOM distance. The contrast follows from this rule: Specification rules may evaluate features on different axes against different eligible ancestors when container selection requires it. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for allow axes to use different containers, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain allow axes to use different containers, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Understand feature-based container selection · Full contents · Next: Account for snapshot updates →

CHAPTER 18 OF 20 · Back to contents

18. Account for snapshot updates

The short answer: Account for snapshot updates is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the account for snapshot updates example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@container scroll-state(stuck:top){.label{padding-block:1rem}}

Expected result and reasoning. The matched style can update after scrolling without allowing its own layout changes to create an immediate circular query. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Expecting every intermediate scroll movement to synchronously restyle inside the same layout calculation misreads the cycle-prevention model. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “At which rendering update was the state sampled?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for account for snapshot updates
• Variable to hold constant: the surrounding setup, so the comparison isolates account for snapshot updates.
• Variable to change: record requestAnimationFrame observations across a scroll
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For account for snapshot updates, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a reading panel. Transfer account for snapshot updates into a reading panel. Preserve the governing rule—Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.—while identifying what changes. Account for snapshot updates is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a timetable card. Transfer account for snapshot updates into a timetable card. Preserve the governing rule—Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.—while identifying what changes. Account for snapshot updates is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a writing-mode test. Transfer account for snapshot updates into a writing-mode test. Preserve the governing rule—Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.—while identifying what changes. Account for snapshot updates is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system component. Transfer account for snapshot updates into a design-system component. Preserve the governing rule—Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.—while identifying what changes. Account for snapshot updates is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for account for snapshot updates, predict the result, then record requestAnimationFrame observations across a scroll. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The matched style can update after scrolling without allowing its own layout changes to create an immediate circular query. The contrast follows from this rule: Scroll-state query results are evaluated from a document snapshot and update at defined rendering steps to avoid style-layout cycles. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for account for snapshot updates, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain account for snapshot updates, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Allow axes to use different containers · Full contents · Next: Build a useful fallback first →

CHAPTER 19 OF 20 · Back to contents

19. Build a useful fallback first

The short answer: Build a useful fallback first is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Scroll-state queries should enhance a component whose base content and controls remain usable without support.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Scroll-state queries should enhance a component whose base content and controls remain usable without support.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the build a useful fallback first example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

.more{visibility:visible}@supports(container-type:scroll-state){.more{opacity:.7}}

Expected result and reasoning. The cue remains present even if the advanced feature is ignored. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Hiding essential navigation by default and revealing it only through a new query creates a support failure. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Can the learner read and operate the component with the query removed?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for build a useful fallback first
• Variable to hold constant: the surrounding setup, so the comparison isolates build a useful fallback first.
• Variable to change: disable the @supports block and complete the task
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For build a useful fallback first, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a horizontal gallery. Transfer build a useful fallback first into a horizontal gallery. Preserve the governing rule—Scroll-state queries should enhance a component whose base content and controls remain usable without support.—while identifying what changes. Build a useful fallback first is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state queries should enhance a component whose base content and controls remain usable without support.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an accessibility review. Transfer build a useful fallback first into an accessibility review. Preserve the governing rule—Scroll-state queries should enhance a component whose base content and controls remain usable without support.—while identifying what changes. Build a useful fallback first is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state queries should enhance a component whose base content and controls remain usable without support.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a browser-support matrix. Transfer build a useful fallback first into a browser-support matrix. Preserve the governing rule—Scroll-state queries should enhance a component whose base content and controls remain usable without support.—while identifying what changes. Build a useful fallback first is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state queries should enhance a component whose base content and controls remain usable without support.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a sticky lesson index. Transfer build a useful fallback first into a sticky lesson index. Preserve the governing rule—Scroll-state queries should enhance a component whose base content and controls remain usable without support.—while identifying what changes. Build a useful fallback first is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Scroll-state queries should enhance a component whose base content and controls remain usable without support.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for build a useful fallback first, predict the result, then disable the @supports block and complete the task. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The cue remains present even if the advanced feature is ignored. The contrast follows from this rule: Scroll-state queries should enhance a component whose base content and controls remain usable without support. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for build a useful fallback first, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain build a useful fallback first, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Account for snapshot updates · Full contents · Next: Test support and accessibility →

CHAPTER 20 OF 20 · Back to contents

20. Test support and accessibility

The short answer: Test support and accessibility is best learned as a decision about the documented contract rather than as a longer snippet to memorise. The governing rule is: Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The implementation applies the rule “Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.”. A minimal fixture exposes the relevant input and observation while excluding unrelated project state. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the test support and accessibility example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

@supports(container-type:scroll-state){@container scroll-state(stuck:top){.label{font-weight:700}}}

Expected result and reasoning. The enhancement avoids motion and uses a non-colour cue, while base content remains available. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Claiming universal browser support or using colour alone turns a technical demo into unreliable guidance. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Which browser version, input method and accessibility setting was verified?”

• Evidence to collect: the exact input, environment version, observed result and governing rule for test support and accessibility
• Variable to hold constant: the surrounding setup, so the comparison isolates test support and accessibility.
• Variable to change: test keyboard, touch, zoom and a different writing mode
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For test support and accessibility, a common unproductive move is to make several changes at once. That can make the symptom disappear while leaving the misconception intact. Reset to the smallest example, keep a brief prediction log, and preserve both the successful and unsuccessful case. The pair becomes a reusable test fixture and a much clearer revision note than a paragraph of definitions.

Four transfer cases

Transfer case 1: a timetable card. Transfer test support and accessibility into a timetable card. Preserve the governing rule—Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.—while identifying what changes. Test support and accessibility is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a writing-mode test. Transfer test support and accessibility into a writing-mode test. Preserve the governing rule—Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.—while identifying what changes. Test support and accessibility is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system component. Transfer test support and accessibility into a design-system component. Preserve the governing rule—Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.—while identifying what changes. Test support and accessibility is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reading panel. Transfer test support and accessibility into a reading panel. Preserve the governing rule—Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.—while identifying what changes. Test support and accessibility is best learned as a decision about the documented contract rather than as a longer snippet to memorise. Record input, prediction, observation and version so disagreement becomes diagnosable. Start by naming the observable evidence, then apply the chapter rule “Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Rebuild the example for test support and accessibility, predict the result, then test keyboard, touch, zoom and a different writing mode. Explain both outcomes without trial and error. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The enhancement avoids motion and uses a non-colour cue, while base content remains available. The contrast follows from this rule: Feature support, keyboard scrolling, zoom, reduced motion, contrast and writing modes all need direct testing; a scroll-state signal is not an accessibility guarantee. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to name the evidence that matters for test support and accessibility, then request one controlled variation. A correct value without a causal explanation is not yet mastery. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

Ready to move on? Move forward when the learner can explain test support and accessibility, solve the worked case without prompts, and handle at least two transfer cases with a changed context. Revisit this chapter when the explanation relies on “usually”, “looks like”, or “the computer says so” without identifying the governing rule.

← Previous: Build a useful fallback first · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered CSS scroll-state() container queries merely because one polished example runs. Look for four behaviours: they can state the rule in plain language; predict before executing; isolate one changed condition; and explain why a transfer case is the same problem or a different one. Those behaviours make progress visible without requiring a parent to become a specialist.

Use a ten-minute check-in. Ask the learner to choose one chapter, reconstruct its example from memory, and narrate the causal chain. Then change one input. If the learner can update the prediction and justify the change, stop. More repetitions are not automatically better. Save the two-case pair and return to it after a few days.

If every answer is hesitant, reduce the scope. Return to the earliest chapter whose rule cannot be stated accurately. If explanations are fluent but real tasks still fail, move to a capstone because the missing skill is likely transfer or diagnosis. If frustration rises, separate typing errors from conceptual errors and solve only one category in that session.

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable CSS fixture that demonstrates scroll-state responsive component styling without unrelated code.

Route. Record environment, input, prediction and output. Keep one nearby contrast. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Another learner can reproduce the observation and explain the separating rule. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but the wrong mechanism.

Route. Change the condition the wrong explanation says matters while holding the real condition constant. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The controlled contrast exposes the misconception. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle a version boundary

Scenario. Two environments produce different observations.

Route. Capture versions, platform, exact input and relevant state. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Bind the claim to the documented environment and retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

Scenario. A parent has ten minutes and no specialist background.

Route. Ask for one rule, prediction, run and changed condition. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The learner demonstrates mastery through causal explanation. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but a project does not.

Route. Preserve the fixture, then compare dependencies one at a time. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The first dependency that changes the result becomes the next diagnostic focus. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after an update.

Route. Save the positive case, near miss and version metadata. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. A useful check reports a meaningful changed observation. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 7: Explain a limitation honestly

Scenario. The feature does not cover an important job or is unavailable.

Route. Name the limitation and the safer route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Good advice is bounded rather than stretched into a guarantee. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related APIs or commands appear equivalent.

Route. Define output, timing, compatibility and failure modes. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Choose the contract that matches the job and reject a tempting mismatch. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is CSS scroll-state() container queries mainly a syntax topic?

No. Syntax is the handle. Mastery means stating the contract, predicting boundary cases, collecting the right evidence and choosing a different tool when the contract does not fit.

How long should one practice session be?

Ten to twenty focused minutes is enough for one rule, one worked example, one near miss and one explanation. Save the fixture and retrieve it again after a gap.

Should every edge case be memorised?

No. Memorise the central rule and organise exceptions by version, platform, input type, browser support or repository state.

What can a non-specialist parent ask?

Ask for a prediction, the rule behind it, the observation that could disprove it and one changed case.

When is copying an example useful?

Copying establishes a baseline. It becomes learning after the student predicts, reconstructs, varies and explains it.

How do we separate setup errors from concept errors?

Run a known-good minimal fixture first. If it fails, inspect version, support and transcription. If it passes but a variation is predicted wrongly, the misconception is conceptual.

Should practice start inside a large project?

Not initially. Begin in a disposable directory, tiny script or isolated page, then transfer the verified rule.

What belongs in revision notes?

Keep one rule, the smallest successful example, a near miss, observed output, environment version and a diagnostic question.

What if two computers disagree?

Treat the difference as evidence. Record versions, exact input and relevant state, then consult the primary source.

When should the learner move on?

Move on when the learner can explain the rule, predict two contrasts, diagnose a broken case and transfer the idea without step-by-step prompting.

References and verification notes

Primary technical source: CSS Conditional Rules Level 5 scroll-state query specification. The CSS Working Group draft defines scroll-state query containers, stuck, snapped and scrollable features, Boolean combination, container selection, logical and physical edges, and snapshot-based updates that prevent style-layout cycles.

The worked examples were checked with Static verification against CSS Conditional Rules Level 5 and its examples; fixtures distinguish descendants from the query container, physical and logical edges, nested eligible containers, stuck/snapped/scrollable conditions, Boolean combinations, fallbacks and accessibility checks without claiming universal browser support. The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

Last reviewed: 17 October 2026. This article is educational guidance for families and learners. It does not advertise a physical Punggol outlet or make admissions, affiliation, score or outcome guarantees.