When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.
JavaScript IntersectionObserver asynchronously reports when a target crosses configured intersection thresholds relative to a root. It replaces repeated manual geometry polling for many visibility jobs, but it does not promise exact pixel-by-pixel updates or prove that a person meaningfully saw content. Mastery means choosing the correct root, margins and thresholds, reading entry geometry and times, and disconnecting or unobserving according to component lifecycle. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.
The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.
Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.
Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.
Find your next learning step
Choose the route that matches the present difficulty. Use the complete index for a systematic course.
Build the model
Chapters 1-4 . Begin here, then continue after the learner can predict, verify and explain.
Use the core tools
Chapters 5-8 . Begin here, then continue after the learner can predict, verify and explain.
Handle boundaries
Chapters 9-12 . Begin here, then continue after the learner can predict, verify and explain.
Debug and verify
Chapters 13-16 . Begin here, then continue after the learner can predict, verify and explain.
Transfer with judgment
Chapters 17-20 . Begin here, then continue after the learner can predict, verify and explain.
Open the full chapter index . Jump to capstone practice . Use the How Studying Works hub . Read the official documentation
Complete chapter index
Chapters 1-4 . Build the model
Chapters 5-8 . Use the core tools
Chapters 9-12 . Handle boundaries
Chapters 13-16 . Debug and verify
CHAPTER 1 OF 20 . Build the model
1. Observers report threshold crossings asynchronously
IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is expecting a synchronous callback immediately after observe. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Observe, wait for delivery and assert the first entry before changing layout.
For the Observers report threshold crossings asynchronously chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting a synchronous callback immediately after observe. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const observer=new IntersectionObserver(entries=>console.log(entries));
observer.observe(card);Explained result. The callback runs asynchronously with an entry describing card relative to the implicit viewport root. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework article. Predict the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root.” Apply this procedure: Observe, wait for delivery and assert the first entry before changing layout. The expected mechanism is: The callback runs asynchronously with an entry describing card relative to the implicit viewport root. For the homework article, add one near-miss that exposes expecting a synchronous callback immediately after observe. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library list. Contrast the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root.” Apply this procedure: Observe, wait for delivery and assert the first entry before changing layout. The expected mechanism is: The callback runs asynchronously with an entry describing card relative to the implicit viewport root. For the library list, add one near-miss that exposes expecting a synchronous callback immediately after observe. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA page. Stress-test the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root.” Apply this procedure: Observe, wait for delivery and assert the first entry before changing layout. The expected mechanism is: The callback runs asynchronously with an entry describing card relative to the implicit viewport root. For the CCA page, add one near-miss that exposes expecting a synchronous callback immediately after observe. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science dashboard. Explain the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root.” Apply this procedure: Observe, wait for delivery and assert the first entry before changing layout. The expected mechanism is: The callback runs asynchronously with an entry describing card relative to the implicit viewport root. For the science dashboard, add one near-miss that exposes expecting a synchronous callback immediately after observe. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers expecting a synchronous callback immediately after observe.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Observe, wait for delivery and assert the first entry before changing layout.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Observers report threshold crossings asynchronously?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting a synchronous callback immediately after observe be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with infinite-list sentinels with duplicate-load protection. Include one ordinary case, one boundary and one deliberate failure caused by expecting a synchronous callback immediately after observe. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root. It shows a trace, not only a final value. The ordinary case should demonstrate “The callback runs asynchronously with an entry describing card relative to the implicit viewport root.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Observe, wait for delivery and assert the first entry before changing layout. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Observers report threshold crossings asynchronously, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is trying to pass different thresholds to observe for each target. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Group targets by a genuinely shared observation policy.
For the The constructor fixes one configuration chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on trying to pass different thresholds to observe for each target. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const observer=new IntersectionObserver(onChange,{threshold:[0,.5,1]});Explained result. Every target observed by this instance uses the same three thresholds. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA page. Contrast the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches.” Apply this procedure: Group targets by a genuinely shared observation policy. The expected mechanism is: Every target observed by this instance uses the same three thresholds. For the CCA page, add one near-miss that exposes trying to pass different thresholds to observe for each target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science dashboard. Stress-test the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches.” Apply this procedure: Group targets by a genuinely shared observation policy. The expected mechanism is: Every target observed by this instance uses the same three thresholds. For the science dashboard, add one near-miss that exposes trying to pass different thresholds to observe for each target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision page. Explain the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches.” Apply this procedure: Group targets by a genuinely shared observation policy. The expected mechanism is: Every target observed by this instance uses the same three thresholds. For the revision page, add one near-miss that exposes trying to pass different thresholds to observe for each target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Transfer the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches.” Apply this procedure: Group targets by a genuinely shared observation policy. The expected mechanism is: Every target observed by this instance uses the same three thresholds. For the family planner, add one near-miss that exposes trying to pass different thresholds to observe for each target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers trying to pass different thresholds to observe for each target.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Group targets by a genuinely shared observation policy.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from The constructor fixes one configuration?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing trying to pass different thresholds to observe for each target be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible navigation with current-section state without stealing focus. Include one ordinary case, one boundary and one deliberate failure caused by trying to pass different thresholds to observe for each target. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches. It shows a trace, not only a final value. The ordinary case should demonstrate “Every target observed by this instance uses the same three thresholds.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Group targets by a genuinely shared observation policy. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For The constructor fixes one configuration, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A null root uses the document viewport as the intersection root under ordinary implicit-root observation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is assuming null means the nearest scrolling ancestor. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Pass the intended scroll container element when it should define visibility.
For the Null root means the top-level viewport chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming null means the nearest scrolling ancestor. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
new IntersectionObserver(onChange,{root:null})Explained result. Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision page. Stress-test the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A null root uses the document viewport as the intersection root under ordinary implicit-root observation.” Apply this procedure: Pass the intended scroll container element when it should define visibility. The expected mechanism is: Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel. For the revision page, add one near-miss that exposes assuming null means the nearest scrolling ancestor. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Explain the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A null root uses the document viewport as the intersection root under ordinary implicit-root observation.” Apply this procedure: Pass the intended scroll container element when it should define visibility. The expected mechanism is: Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel. For the family planner, add one near-miss that exposes assuming null means the nearest scrolling ancestor. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible navigation. Transfer the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A null root uses the document viewport as the intersection root under ordinary implicit-root observation.” Apply this procedure: Pass the intended scroll container element when it should define visibility. The expected mechanism is: Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel. For the accessible navigation, add one near-miss that exposes assuming null means the nearest scrolling ancestor. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Predict the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A null root uses the document viewport as the intersection root under ordinary implicit-root observation.” Apply this procedure: Pass the intended scroll container element when it should define visibility. The expected mechanism is: Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel. For the browser fixture, add one near-miss that exposes assuming null means the nearest scrolling ancestor. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers assuming null means the nearest scrolling ancestor.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Pass the intended scroll container element when it should define visibility.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Null root means the top-level viewport?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming null means the nearest scrolling ancestor be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny browser fixture with controlled root, target and threshold assertions. Include one ordinary case, one boundary and one deliberate failure caused by assuming null means the nearest scrolling ancestor. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A null root uses the document viewport as the intersection root under ordinary implicit-root observation. It shows a trace, not only a final value. The ordinary case should demonstrate “Targets are evaluated against the top-level viewport rather than an arbitrary ancestor panel.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Pass the intended scroll container element when it should define visibility. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Null root means the top-level viewport, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 4 OF 20 . Build the model
4. An explicit root needs a containment relationship
With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is selecting a visually nearby panel that does not actually contain the target. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect DOM and layout containment before blaming thresholds.
For the An explicit root needs a containment relationship chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on selecting a visually nearby panel that does not actually contain the target. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
new IntersectionObserver(onChange,{root:scroller})Explained result. The observer computes intersections against scroller for suitable target descendants. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible navigation. Explain the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation.” Apply this procedure: Inspect DOM and layout containment before blaming thresholds. The expected mechanism is: The observer computes intersections against scroller for suitable target descendants. For the accessible navigation, add one near-miss that exposes selecting a visually nearby panel that does not actually contain the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: browser fixture. Transfer the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation.” Apply this procedure: Inspect DOM and layout containment before blaming thresholds. The expected mechanism is: The observer computes intersections against scroller for suitable target descendants. For the browser fixture, add one near-miss that exposes selecting a visually nearby panel that does not actually contain the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework article. Predict the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation.” Apply this procedure: Inspect DOM and layout containment before blaming thresholds. The expected mechanism is: The observer computes intersections against scroller for suitable target descendants. For the homework article, add one near-miss that exposes selecting a visually nearby panel that does not actually contain the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library list. Contrast the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation.” Apply this procedure: Inspect DOM and layout containment before blaming thresholds. The expected mechanism is: The observer computes intersections against scroller for suitable target descendants. For the library list, add one near-miss that exposes selecting a visually nearby panel that does not actually contain the target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers selecting a visually nearby panel that does not actually contain the target.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect DOM and layout containment before blaming thresholds.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from An explicit root needs a containment relationship?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing selecting a visually nearby panel that does not actually contain the target be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework article with a reading progress marker and chapter cards. Include one ordinary case, one boundary and one deliberate failure caused by selecting a visually nearby panel that does not actually contain the target. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation. It shows a trace, not only a final value. The ordinary case should demonstrate “The observer computes intersections against scroller for suitable target descendants.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect DOM and layout containment before blaming thresholds. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For An explicit root needs a containment relationship, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling a positive bottom margin extra target size. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw the adjusted root rectangle and test an early-load boundary.
For the rootMargin expands or contracts root bounds chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling a positive bottom margin extra target size. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
{rootMargin:'0px 0px 200px 0px'}Explained result. The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework article. Transfer the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units.” Apply this procedure: Draw the adjusted root rectangle and test an early-load boundary. The expected mechanism is: The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification. For the homework article, add one near-miss that exposes calling a positive bottom margin extra target size. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library list. Predict the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units.” Apply this procedure: Draw the adjusted root rectangle and test an early-load boundary. The expected mechanism is: The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification. For the library list, add one near-miss that exposes calling a positive bottom margin extra target size. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA page. Contrast the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units.” Apply this procedure: Draw the adjusted root rectangle and test an early-load boundary. The expected mechanism is: The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification. For the CCA page, add one near-miss that exposes calling a positive bottom margin extra target size. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science dashboard. Stress-test the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units.” Apply this procedure: Draw the adjusted root rectangle and test an early-load boundary. The expected mechanism is: The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification. For the science dashboard, add one near-miss that exposes calling a positive bottom margin extra target size. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling a positive bottom margin extra target size.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Draw the adjusted root rectangle and test an early-load boundary.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from rootMargin expands or contracts root bounds?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling a positive bottom margin extra target size be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library list with images loaded shortly before they enter view. Include one ordinary case, one boundary and one deliberate failure caused by calling a positive bottom margin extra target size. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: rootMargin applies CSS-like offsets to the root rectangle before intersection testing, with one to four components and restricted units. It shows a trace, not only a final value. The ordinary case should demonstrate “The effective root extends 200 pixels below its normal bottom edge, allowing earlier notification.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Draw the adjusted root rectangle and test an early-load boundary. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For rootMargin expands or contracts root bounds, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using 50 for fifty percent instead of 0.5. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Validate values and inspect observer.thresholds.
For the Thresholds are sorted ratios chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using 50 for fifty percent instead of 0.5. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const io=new IntersectionObserver(cb,{threshold:[1,0,.5]});
console.log(io.thresholds);Explained result. The exposed list is sorted as 0, 0.5 and 1. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA page. Predict the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list.” Apply this procedure: Validate values and inspect observer.thresholds. The expected mechanism is: The exposed list is sorted as 0, 0.5 and 1. For the CCA page, add one near-miss that exposes using 50 for fifty percent instead of 0.5. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science dashboard. Contrast the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list.” Apply this procedure: Validate values and inspect observer.thresholds. The expected mechanism is: The exposed list is sorted as 0, 0.5 and 1. For the science dashboard, add one near-miss that exposes using 50 for fifty percent instead of 0.5. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision page. Stress-test the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list.” Apply this procedure: Validate values and inspect observer.thresholds. The expected mechanism is: The exposed list is sorted as 0, 0.5 and 1. For the revision page, add one near-miss that exposes using 50 for fifty percent instead of 0.5. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Explain the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list.” Apply this procedure: Validate values and inspect observer.thresholds. The expected mechanism is: The exposed list is sorted as 0, 0.5 and 1. For the family planner, add one near-miss that exposes using 50 for fifty percent instead of 0.5. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using 50 for fifty percent instead of 0.5.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Validate values and inspect observer.thresholds.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Thresholds are sorted ratios?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using 50 for fifty percent instead of 0.5 be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA page with an active section indicator inside a scroll panel. Include one ordinary case, one boundary and one deliberate failure caused by using 50 for fifty percent instead of 0.5. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: threshold accepts one number or a sequence from zero to one, and the observer exposes a sorted thresholds list. It shows a trace, not only a final value. The ordinary case should demonstrate “The exposed list is sorted as 0, 0.5 and 1.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Validate values and inspect observer.thresholds. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Thresholds are sorted ratios, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using 1 for a large target that can never fit inside the root. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Compare target and root dimensions before selecting full visibility.
For the Zero and one express different boundaries chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using 1 for a large target that can never fit inside the root. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
new IntersectionObserver(cb,{threshold:1})Explained result. The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision page. Contrast the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping.” Apply this procedure: Compare target and root dimensions before selecting full visibility. The expected mechanism is: The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. For the revision page, add one near-miss that exposes using 1 for a large target that can never fit inside the root. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Stress-test the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping.” Apply this procedure: Compare target and root dimensions before selecting full visibility. The expected mechanism is: The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. For the family planner, add one near-miss that exposes using 1 for a large target that can never fit inside the root. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible navigation. Explain the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping.” Apply this procedure: Compare target and root dimensions before selecting full visibility. The expected mechanism is: The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. For the accessible navigation, add one near-miss that exposes using 1 for a large target that can never fit inside the root. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Transfer the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping.” Apply this procedure: Compare target and root dimensions before selecting full visibility. The expected mechanism is: The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. For the browser fixture, add one near-miss that exposes using 1 for a large target that can never fit inside the root. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers using 1 for a large target that can never fit inside the root.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Compare target and root dimensions before selecting full visibility.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Zero and one express different boundaries?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using 1 for a large target that can never fit inside the root be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science dashboard with cards becoming visible in a fixed viewport. Include one ordinary case, one boundary and one deliberate failure caused by using 1 for a large target that can never fit inside the root. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping. It shows a trace, not only a final value. The ordinary case should demonstrate “The callback can report full intersection only when geometry permits the target’s entire area inside the effective root.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Compare target and root dimensions before selecting full visibility. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Zero and one express different boundaries, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is querying every card again instead of using the delivered entry. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Branch on entry.target and log the supplied rectangles.
For the Entries identify target and geometry chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on querying every card again instead of using the delivered entry. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
for(const entry of entries) console.log(entry.target,entry.intersectionRatio);Explained result. Each entry carries the target-specific observation needed for a focused update. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible navigation. Stress-test the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags.” Apply this procedure: Branch on entry.target and log the supplied rectangles. The expected mechanism is: Each entry carries the target-specific observation needed for a focused update. For the accessible navigation, add one near-miss that exposes querying every card again instead of using the delivered entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: browser fixture. Explain the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags.” Apply this procedure: Branch on entry.target and log the supplied rectangles. The expected mechanism is: Each entry carries the target-specific observation needed for a focused update. For the browser fixture, add one near-miss that exposes querying every card again instead of using the delivered entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework article. Transfer the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags.” Apply this procedure: Branch on entry.target and log the supplied rectangles. The expected mechanism is: Each entry carries the target-specific observation needed for a focused update. For the homework article, add one near-miss that exposes querying every card again instead of using the delivered entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library list. Predict the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags.” Apply this procedure: Branch on entry.target and log the supplied rectangles. The expected mechanism is: Each entry carries the target-specific observation needed for a focused update. For the library list, add one near-miss that exposes querying every card again instead of using the delivered entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers querying every card again instead of using the delivered entry.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Branch on entry.target and log the supplied rectangles.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Entries identify target and geometry?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing querying every card again instead of using the delivered entry be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision page with practice answers revealed near the learner. Include one ordinary case, one boundary and one deliberate failure caused by querying every card again instead of using the delivered entry. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Each IntersectionObserverEntry reports the target plus boundingClientRect, rootBounds, intersectionRect, intersectionRatio, time and state flags. It shows a trace, not only a final value. The ordinary case should demonstrate “Each entry carries the target-specific observation needed for a focused update.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Branch on entry.target and log the supplied rectangles. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Entries identify target and geometry, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 9 OF 20 . Handle boundaries
9. isIntersecting is not the same as a chosen ratio
isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is treating isIntersecting as proof that half the element is visible. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check the ratio against the product requirement.
For the isIntersecting is not the same as a chosen ratio chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating isIntersecting as proof that half the element is visible. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
if(entry.isIntersecting && entry.intersectionRatio>=.5) markActive();Explained result. The condition states both some intersection and the application’s half-visible rule. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework article. Explain the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds.” Apply this procedure: Check the ratio against the product requirement. The expected mechanism is: The condition states both some intersection and the application’s half-visible rule. For the homework article, add one near-miss that exposes treating isIntersecting as proof that half the element is visible. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library list. Transfer the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds.” Apply this procedure: Check the ratio against the product requirement. The expected mechanism is: The condition states both some intersection and the application’s half-visible rule. For the library list, add one near-miss that exposes treating isIntersecting as proof that half the element is visible. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA page. Predict the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds.” Apply this procedure: Check the ratio against the product requirement. The expected mechanism is: The condition states both some intersection and the application’s half-visible rule. For the CCA page, add one near-miss that exposes treating isIntersecting as proof that half the element is visible. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science dashboard. Contrast the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds.” Apply this procedure: Check the ratio against the product requirement. The expected mechanism is: The condition states both some intersection and the application’s half-visible rule. For the science dashboard, add one near-miss that exposes treating isIntersecting as proof that half the element is visible. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers treating isIntersecting as proof that half the element is visible.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Check the ratio against the product requirement.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from isIntersecting is not the same as a chosen ratio?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating isIntersecting as proof that half the element is visible be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with infinite-list sentinels with duplicate-load protection. Include one ordinary case, one boundary and one deliberate failure caused by treating isIntersecting as proof that half the element is visible. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: isIntersecting records transition into or out of intersection, while intersectionRatio expresses the visible area ratio used with thresholds. It shows a trace, not only a final value. The ordinary case should demonstrate “The condition states both some intersection and the application’s half-visible rule.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Check the ratio against the product requirement. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For isIntersecting is not the same as a chosen ratio, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is copying a 0.75 threshold from card components to full chapters. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Measure representative geometry and use low thresholds or sentinels when appropriate.
For the Large targets need a suitable policy chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on copying a 0.75 threshold from card components to full chapters. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const io=new IntersectionObserver(cb,{threshold:.1});Explained result. A lower ratio can create a reachable chapter-entry signal for tall sections. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA page. Transfer the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport.” Apply this procedure: Measure representative geometry and use low thresholds or sentinels when appropriate. The expected mechanism is: A lower ratio can create a reachable chapter-entry signal for tall sections. For the CCA page, add one near-miss that exposes copying a 0.75 threshold from card components to full chapters. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science dashboard. Predict the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport.” Apply this procedure: Measure representative geometry and use low thresholds or sentinels when appropriate. The expected mechanism is: A lower ratio can create a reachable chapter-entry signal for tall sections. For the science dashboard, add one near-miss that exposes copying a 0.75 threshold from card components to full chapters. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision page. Contrast the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport.” Apply this procedure: Measure representative geometry and use low thresholds or sentinels when appropriate. The expected mechanism is: A lower ratio can create a reachable chapter-entry signal for tall sections. For the revision page, add one near-miss that exposes copying a 0.75 threshold from card components to full chapters. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Stress-test the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport.” Apply this procedure: Measure representative geometry and use low thresholds or sentinels when appropriate. The expected mechanism is: A lower ratio can create a reachable chapter-entry signal for tall sections. For the family planner, add one near-miss that exposes copying a 0.75 threshold from card components to full chapters. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers copying a 0.75 threshold from card components to full chapters.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Measure representative geometry and use low thresholds or sentinels when appropriate.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Large targets need a suitable policy?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing copying a 0.75 threshold from card components to full chapters be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible navigation with current-section state without stealing focus. Include one ordinary case, one boundary and one deliberate failure caused by copying a 0.75 threshold from card components to full chapters. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport. It shows a trace, not only a final value. The ordinary case should demonstrate “A lower ratio can create a reachable chapter-entry signal for tall sections.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Measure representative geometry and use low thresholds or sentinels when appropriate. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Large targets need a suitable policy, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reasoning from document position while ignoring overflow clipping. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect each clipping ancestor and the entry’s intersectionRect.
For the Clipping changes the final intersection chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reasoning from document position while ignoring overflow clipping. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
console.log(entry.boundingClientRect,entry.intersectionRect);Explained result. The difference reveals how much of the target rectangle survives clipping. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision page. Predict the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds.” Apply this procedure: Inspect each clipping ancestor and the entry’s intersectionRect. The expected mechanism is: The difference reveals how much of the target rectangle survives clipping. For the revision page, add one near-miss that exposes reasoning from document position while ignoring overflow clipping. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Contrast the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds.” Apply this procedure: Inspect each clipping ancestor and the entry’s intersectionRect. The expected mechanism is: The difference reveals how much of the target rectangle survives clipping. For the family planner, add one near-miss that exposes reasoning from document position while ignoring overflow clipping. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible navigation. Stress-test the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds.” Apply this procedure: Inspect each clipping ancestor and the entry’s intersectionRect. The expected mechanism is: The difference reveals how much of the target rectangle survives clipping. For the accessible navigation, add one near-miss that exposes reasoning from document position while ignoring overflow clipping. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Explain the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds.” Apply this procedure: Inspect each clipping ancestor and the entry’s intersectionRect. The expected mechanism is: The difference reveals how much of the target rectangle survives clipping. For the browser fixture, add one near-miss that exposes reasoning from document position while ignoring overflow clipping. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reasoning from document position while ignoring overflow clipping.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Inspect each clipping ancestor and the entry’s intersectionRect.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Clipping changes the final intersection?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reasoning from document position while ignoring overflow clipping be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny browser fixture with controlled root, target and threshold assertions. Include one ordinary case, one boundary and one deliberate failure caused by reasoning from document position while ignoring overflow clipping. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: The algorithm intersects target bounds with clipping ancestors, nested browsing contexts and the root bounds. It shows a trace, not only a final value. The ordinary case should demonstrate “The difference reveals how much of the target rectangle survives clipping.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Inspect each clipping ancestor and the entry’s intersectionRect. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Clipping changes the final intersection, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
One observer can register multiple targets that share the same policy, with entries delivered in a batch. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is creating hundreds of identical observer instances unnecessarily. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Reuse one observer and map entry.target to component state.
For the observe can watch many targets chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on creating hundreds of identical observer instances unnecessarily. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
document.querySelectorAll('.card').forEach(el=>observer.observe(el));Explained result. All cards share the observer configuration while keeping target-specific entries. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible navigation. Contrast the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer can register multiple targets that share the same policy, with entries delivered in a batch.” Apply this procedure: Reuse one observer and map entry.target to component state. The expected mechanism is: All cards share the observer configuration while keeping target-specific entries. For the accessible navigation, add one near-miss that exposes creating hundreds of identical observer instances unnecessarily. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: browser fixture. Stress-test the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer can register multiple targets that share the same policy, with entries delivered in a batch.” Apply this procedure: Reuse one observer and map entry.target to component state. The expected mechanism is: All cards share the observer configuration while keeping target-specific entries. For the browser fixture, add one near-miss that exposes creating hundreds of identical observer instances unnecessarily. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework article. Explain the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer can register multiple targets that share the same policy, with entries delivered in a batch.” Apply this procedure: Reuse one observer and map entry.target to component state. The expected mechanism is: All cards share the observer configuration while keeping target-specific entries. For the homework article, add one near-miss that exposes creating hundreds of identical observer instances unnecessarily. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library list. Transfer the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “One observer can register multiple targets that share the same policy, with entries delivered in a batch.” Apply this procedure: Reuse one observer and map entry.target to component state. The expected mechanism is: All cards share the observer configuration while keeping target-specific entries. For the library list, add one near-miss that exposes creating hundreds of identical observer instances unnecessarily. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers creating hundreds of identical observer instances unnecessarily.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Reuse one observer and map entry.target to component state.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from observe can watch many targets?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing creating hundreds of identical observer instances unnecessarily be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework article with a reading progress marker and chapter cards. Include one ordinary case, one boundary and one deliberate failure caused by creating hundreds of identical observer instances unnecessarily. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: One observer can register multiple targets that share the same policy, with entries delivered in a batch. It shows a trace, not only a final value. The ordinary case should demonstrate “All cards share the observer configuration while keeping target-specific entries.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Reuse one observer and map entry.target to component state. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For observe can watch many targets, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
unobserve stops observing a specified target while leaving other registrations active. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling disconnect after one lazy image loads and disabling every other target. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Unobserve only the completed target.
For the unobserve removes one target chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling disconnect after one lazy image loads and disabling every other target. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
image.src=image.dataset.src; observer.unobserve(image);Explained result. The loaded image stops producing entries while other images remain observed. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework article. Stress-test the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “unobserve stops observing a specified target while leaving other registrations active.” Apply this procedure: Unobserve only the completed target. The expected mechanism is: The loaded image stops producing entries while other images remain observed. For the homework article, add one near-miss that exposes calling disconnect after one lazy image loads and disabling every other target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library list. Explain the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “unobserve stops observing a specified target while leaving other registrations active.” Apply this procedure: Unobserve only the completed target. The expected mechanism is: The loaded image stops producing entries while other images remain observed. For the library list, add one near-miss that exposes calling disconnect after one lazy image loads and disabling every other target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA page. Transfer the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “unobserve stops observing a specified target while leaving other registrations active.” Apply this procedure: Unobserve only the completed target. The expected mechanism is: The loaded image stops producing entries while other images remain observed. For the CCA page, add one near-miss that exposes calling disconnect after one lazy image loads and disabling every other target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science dashboard. Predict the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “unobserve stops observing a specified target while leaving other registrations active.” Apply this procedure: Unobserve only the completed target. The expected mechanism is: The loaded image stops producing entries while other images remain observed. For the science dashboard, add one near-miss that exposes calling disconnect after one lazy image loads and disabling every other target. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling disconnect after one lazy image loads and disabling every other target.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Unobserve only the completed target.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from unobserve removes one target?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling disconnect after one lazy image loads and disabling every other target be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library list with images loaded shortly before they enter view. Include one ordinary case, one boundary and one deliberate failure caused by calling disconnect after one lazy image loads and disabling every other target. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: unobserve stops observing a specified target while leaving other registrations active. It shows a trace, not only a final value. The ordinary case should demonstrate “The loaded image stops producing entries while other images remain observed.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Unobserve only the completed target. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For unobserve removes one target, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
disconnect stops observing every target registered with that observer. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is removing a component but leaving its observer and captured state alive. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Disconnect during component teardown.
For the disconnect clears all targets chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on removing a component but leaving its observer and captured state alive. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
observer.disconnect();Explained result. All registrations for that observer are removed. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA page. Explain the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “disconnect stops observing every target registered with that observer.” Apply this procedure: Disconnect during component teardown. The expected mechanism is: All registrations for that observer are removed. For the CCA page, add one near-miss that exposes removing a component but leaving its observer and captured state alive. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science dashboard. Transfer the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “disconnect stops observing every target registered with that observer.” Apply this procedure: Disconnect during component teardown. The expected mechanism is: All registrations for that observer are removed. For the science dashboard, add one near-miss that exposes removing a component but leaving its observer and captured state alive. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision page. Predict the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “disconnect stops observing every target registered with that observer.” Apply this procedure: Disconnect during component teardown. The expected mechanism is: All registrations for that observer are removed. For the revision page, add one near-miss that exposes removing a component but leaving its observer and captured state alive. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Contrast the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “disconnect stops observing every target registered with that observer.” Apply this procedure: Disconnect during component teardown. The expected mechanism is: All registrations for that observer are removed. For the family planner, add one near-miss that exposes removing a component but leaving its observer and captured state alive. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers removing a component but leaving its observer and captured state alive.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Disconnect during component teardown.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from disconnect clears all targets?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing removing a component but leaving its observer and captured state alive be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA page with an active section indicator inside a scroll panel. Include one ordinary case, one boundary and one deliberate failure caused by removing a component but leaving its observer and captured state alive. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: disconnect stops observing every target registered with that observer. It shows a trace, not only a final value. The ordinary case should demonstrate “All registrations for that observer are removed.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Disconnect during component teardown. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For disconnect clears all targets, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
takeRecords returns queued but not yet delivered entries and empties the queue. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling takeRecords and then expecting the same entries in the callback. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Process the returned entries explicitly during controlled cleanup or tests.
For the takeRecords drains queued entries chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling takeRecords and then expecting the same entries in the callback. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const pending=observer.takeRecords();Explained result. pending contains the drained observations and they are no longer queued for ordinary callback delivery. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision page. Transfer the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “takeRecords returns queued but not yet delivered entries and empties the queue.” Apply this procedure: Process the returned entries explicitly during controlled cleanup or tests. The expected mechanism is: pending contains the drained observations and they are no longer queued for ordinary callback delivery. For the revision page, add one near-miss that exposes calling takeRecords and then expecting the same entries in the callback. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Predict the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “takeRecords returns queued but not yet delivered entries and empties the queue.” Apply this procedure: Process the returned entries explicitly during controlled cleanup or tests. The expected mechanism is: pending contains the drained observations and they are no longer queued for ordinary callback delivery. For the family planner, add one near-miss that exposes calling takeRecords and then expecting the same entries in the callback. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible navigation. Contrast the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “takeRecords returns queued but not yet delivered entries and empties the queue.” Apply this procedure: Process the returned entries explicitly during controlled cleanup or tests. The expected mechanism is: pending contains the drained observations and they are no longer queued for ordinary callback delivery. For the accessible navigation, add one near-miss that exposes calling takeRecords and then expecting the same entries in the callback. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Stress-test the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “takeRecords returns queued but not yet delivered entries and empties the queue.” Apply this procedure: Process the returned entries explicitly during controlled cleanup or tests. The expected mechanism is: pending contains the drained observations and they are no longer queued for ordinary callback delivery. For the browser fixture, add one near-miss that exposes calling takeRecords and then expecting the same entries in the callback. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling takeRecords and then expecting the same entries in the callback.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Process the returned entries explicitly during controlled cleanup or tests.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from takeRecords drains queued entries?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling takeRecords and then expecting the same entries in the callback be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science dashboard with cards becoming visible in a fixed viewport. Include one ordinary case, one boundary and one deliberate failure caused by calling takeRecords and then expecting the same entries in the callback. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: takeRecords returns queued but not yet delivered entries and empties the queue. It shows a trace, not only a final value. The ordinary case should demonstrate “pending contains the drained observations and they are no longer queued for ordinary callback delivery.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Process the returned entries explicitly during controlled cleanup or tests. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For takeRecords drains queued entries, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A sentinel or image can intersect more than once as scrolling and layout change. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is starting the same network request on every intersecting entry. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Set a loading state or unobserve after committing the one-time action.
For the Lazy loading needs duplicate-work protection chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on starting the same network request on every intersecting entry. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
if(entry.isIntersecting&&!card.dataset.loading){card.dataset.loading='1';load();}Explained result. The guard prevents repeated loads while the same target crosses boundaries again. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible navigation. Predict the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sentinel or image can intersect more than once as scrolling and layout change.” Apply this procedure: Set a loading state or unobserve after committing the one-time action. The expected mechanism is: The guard prevents repeated loads while the same target crosses boundaries again. For the accessible navigation, add one near-miss that exposes starting the same network request on every intersecting entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: browser fixture. Contrast the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sentinel or image can intersect more than once as scrolling and layout change.” Apply this procedure: Set a loading state or unobserve after committing the one-time action. The expected mechanism is: The guard prevents repeated loads while the same target crosses boundaries again. For the browser fixture, add one near-miss that exposes starting the same network request on every intersecting entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework article. Stress-test the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sentinel or image can intersect more than once as scrolling and layout change.” Apply this procedure: Set a loading state or unobserve after committing the one-time action. The expected mechanism is: The guard prevents repeated loads while the same target crosses boundaries again. For the homework article, add one near-miss that exposes starting the same network request on every intersecting entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library list. Explain the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A sentinel or image can intersect more than once as scrolling and layout change.” Apply this procedure: Set a loading state or unobserve after committing the one-time action. The expected mechanism is: The guard prevents repeated loads while the same target crosses boundaries again. For the library list, add one near-miss that exposes starting the same network request on every intersecting entry. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers starting the same network request on every intersecting entry.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Set a loading state or unobserve after committing the one-time action.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Lazy loading needs duplicate-work protection?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing starting the same network request on every intersecting entry be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision page with practice answers revealed near the learner. Include one ordinary case, one boundary and one deliberate failure caused by starting the same network request on every intersecting entry. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A sentinel or image can intersect more than once as scrolling and layout change. It shows a trace, not only a final value. The ordinary case should demonstrate “The guard prevents repeated loads while the same target crosses boundaries again.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Set a loading state or unobserve after committing the one-time action. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Lazy loading needs duplicate-work protection, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is moving the sentinel and launching overlapping page loads. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use one in-flight promise and a hasMore flag.
For the Infinite scroll needs backpressure chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on moving the sentinel and launching overlapping page loads. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
if(entry.isIntersecting&&hasMore&&!loading) loadNextPage();Explained result. The observer supplies a signal; application state controls request safety. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: homework article. Contrast the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page.” Apply this procedure: Use one in-flight promise and a hasMore flag. The expected mechanism is: The observer supplies a signal; application state controls request safety. For the homework article, add one near-miss that exposes moving the sentinel and launching overlapping page loads. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: library list. Stress-test the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page.” Apply this procedure: Use one in-flight promise and a hasMore flag. The expected mechanism is: The observer supplies a signal; application state controls request safety. For the library list, add one near-miss that exposes moving the sentinel and launching overlapping page loads. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: CCA page. Explain the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page.” Apply this procedure: Use one in-flight promise and a hasMore flag. The expected mechanism is: The observer supplies a signal; application state controls request safety. For the CCA page, add one near-miss that exposes moving the sentinel and launching overlapping page loads. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: science dashboard. Transfer the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page.” Apply this procedure: Use one in-flight promise and a hasMore flag. The expected mechanism is: The observer supplies a signal; application state controls request safety. For the science dashboard, add one near-miss that exposes moving the sentinel and launching overlapping page loads. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers moving the sentinel and launching overlapping page loads.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use one in-flight promise and a hasMore flag.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Infinite scroll needs backpressure?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing moving the sentinel and launching overlapping page loads be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny family planner with infinite-list sentinels with duplicate-load protection. Include one ordinary case, one boundary and one deliberate failure caused by moving the sentinel and launching overlapping page loads. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: A bottom sentinel can trigger pagination, but the application must serialize requests and stop at the final page. It shows a trace, not only a final value. The ordinary case should demonstrate “The observer supplies a signal; application state controls request safety.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use one in-flight promise and a hasMore flag. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Infinite scroll needs backpressure, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 18 OF 20 . Transfer with judgment
18. Section highlighting should not steal focus
Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is calling focus whenever a section becomes active during scrolling. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate passive location indication from deliberate user focus.
For the Section highlighting should not steal focus chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on calling focus whenever a section becomes active during scrolling. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
link.toggleAttribute('aria-current',entry.isIntersecting);Explained result. The navigation state changes without interrupting typing or screen-reader position. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: CCA page. Stress-test the rule using an active section indicator inside a scroll panel. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change.” Apply this procedure: Separate passive location indication from deliberate user focus. The expected mechanism is: The navigation state changes without interrupting typing or screen-reader position. For the CCA page, add one near-miss that exposes calling focus whenever a section becomes active during scrolling. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: science dashboard. Explain the rule using cards becoming visible in a fixed viewport. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change.” Apply this procedure: Separate passive location indication from deliberate user focus. The expected mechanism is: The navigation state changes without interrupting typing or screen-reader position. For the science dashboard, add one near-miss that exposes calling focus whenever a section becomes active during scrolling. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision page. Transfer the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change.” Apply this procedure: Separate passive location indication from deliberate user focus. The expected mechanism is: The navigation state changes without interrupting typing or screen-reader position. For the revision page, add one near-miss that exposes calling focus whenever a section becomes active during scrolling. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: family planner. Predict the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change.” Apply this procedure: Separate passive location indication from deliberate user focus. The expected mechanism is: The navigation state changes without interrupting typing or screen-reader position. For the family planner, add one near-miss that exposes calling focus whenever a section becomes active during scrolling. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers calling focus whenever a section becomes active during scrolling.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Separate passive location indication from deliberate user focus.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Section highlighting should not steal focus?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling focus whenever a section becomes active during scrolling be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessible navigation with current-section state without stealing focus. Include one ordinary case, one boundary and one deliberate failure caused by calling focus whenever a section becomes active during scrolling. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Intersection state can update aria-current or visual navigation without moving keyboard focus or announcing every pixel change. It shows a trace, not only a final value. The ordinary case should demonstrate “The navigation state changes without interrupting typing or screen-reader position.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Separate passive location indication from deliberate user focus. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Section highlighting should not steal focus, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is recording an intersection as a completed lesson. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Combine explicit learner action and appropriate visibility signals for meaningful progress.
For the Observation is not proof of attention chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on recording an intersection as a completed lesson. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const seenGeometry=entry.isIntersecting;Explained result. The boolean is one technical observation, not a human-learning conclusion. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision page. Explain the rule using practice answers revealed near the learner. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it.” Apply this procedure: Combine explicit learner action and appropriate visibility signals for meaningful progress. The expected mechanism is: The boolean is one technical observation, not a human-learning conclusion. For the revision page, add one near-miss that exposes recording an intersection as a completed lesson. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Transfer the rule using infinite-list sentinels with duplicate-load protection. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it.” Apply this procedure: Combine explicit learner action and appropriate visibility signals for meaningful progress. The expected mechanism is: The boolean is one technical observation, not a human-learning conclusion. For the family planner, add one near-miss that exposes recording an intersection as a completed lesson. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessible navigation. Predict the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it.” Apply this procedure: Combine explicit learner action and appropriate visibility signals for meaningful progress. The expected mechanism is: The boolean is one technical observation, not a human-learning conclusion. For the accessible navigation, add one near-miss that exposes recording an intersection as a completed lesson. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Contrast the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it.” Apply this procedure: Combine explicit learner action and appropriate visibility signals for meaningful progress. The expected mechanism is: The boolean is one technical observation, not a human-learning conclusion. For the browser fixture, add one near-miss that exposes recording an intersection as a completed lesson. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers recording an intersection as a completed lesson.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Combine explicit learner action and appropriate visibility signals for meaningful progress.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Observation is not proof of attention?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing recording an intersection as a completed lesson be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny browser fixture with controlled root, target and threshold assertions. Include one ordinary case, one boundary and one deliberate failure caused by recording an intersection as a completed lesson. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it. It shows a trace, not only a final value. The ordinary case should demonstrate “The boolean is one technical observation, not a human-learning conclusion.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Combine explicit learner action and appropriate visibility signals for meaningful progress. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Observation is not proof of attention, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 20 OF 20 . Transfer with judgment
20. Tests need real geometry and lifecycle cleanup
Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is mocking every result without one browser integration test. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use deterministic sizes and avoid arbitrary long timeouts.
For the Tests need real geometry and lifecycle cleanup chapter on JavaScript IntersectionObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mocking every result without one browser integration test. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
observer.observe(target);
// scroll controlled root, await callback, then disconnectExplained result. The fixture proves root, threshold and cleanup behaviour in the target browser. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: accessible navigation. Transfer the rule using current-section state without stealing focus. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect.” Apply this procedure: Use deterministic sizes and avoid arbitrary long timeouts. The expected mechanism is: The fixture proves root, threshold and cleanup behaviour in the target browser. For the accessible navigation, add one near-miss that exposes mocking every result without one browser integration test. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: browser fixture. Predict the rule using controlled root, target and threshold assertions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect.” Apply this procedure: Use deterministic sizes and avoid arbitrary long timeouts. The expected mechanism is: The fixture proves root, threshold and cleanup behaviour in the target browser. For the browser fixture, add one near-miss that exposes mocking every result without one browser integration test. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: homework article. Contrast the rule using a reading progress marker and chapter cards. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect.” Apply this procedure: Use deterministic sizes and avoid arbitrary long timeouts. The expected mechanism is: The fixture proves root, threshold and cleanup behaviour in the target browser. For the homework article, add one near-miss that exposes mocking every result without one browser integration test. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: library list. Stress-test the rule using images loaded shortly before they enter view. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect.” Apply this procedure: Use deterministic sizes and avoid arbitrary long timeouts. The expected mechanism is: The fixture proves root, threshold and cleanup behaviour in the target browser. For the library list, add one near-miss that exposes mocking every result without one browser integration test. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers mocking every result without one browser integration test.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use deterministic sizes and avoid arbitrary long timeouts.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript IntersectionObserver syntax. For this chapter, useful prompts are: “What did you expect from Tests need real geometry and lifecycle cleanup?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mocking every result without one browser integration test be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework article with a reading progress marker and chapter cards. Include one ordinary case, one boundary and one deliberate failure caused by mocking every result without one browser integration test. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: Reliable tests create a controlled root and target, change scroll or dimensions, wait for delivery, assert entries and disconnect. It shows a trace, not only a final value. The ordinary case should demonstrate “The fixture proves root, threshold and cleanup behaviour in the target browser.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use deterministic sizes and avoid arbitrary long timeouts. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Tests need real geometry and lifecycle cleanup, separate the documented JavaScript IntersectionObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
Parent guide: choose the next useful step
Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.
Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.
Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.
Capstone practice with explained routes
1. homework article: model, boundary and recovery
Create a small homework article using a reading progress marker and chapter cards. Combine “Observers report threshold crossings asynchronously” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: IntersectionObserver queues entries when observed targets cross configured visibility thresholds relative to a root. Apply: Observe, wait for delivery and assert the first entry before changing layout. Verify: The callback runs asynchronously with an entry describing card relative to the implicit viewport root. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
2. library list: model, boundary and recovery
Create a small library list using images loaded shortly before they enter view. Combine “An explicit root needs a containment relationship” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: With an element root, observed targets must be descendants in the root’s containing-block chain for meaningful same-document observation. Apply: Inspect DOM and layout containment before blaming thresholds. Verify: The observer computes intersections against scroller for suitable target descendants. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
3. CCA page: model, boundary and recovery
Create a small CCA page using an active section indicator inside a scroll panel. Combine “Zero and one express different boundaries” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Threshold 0 concerns transition between no intersection and some intersection state, while 1 requires full intersection subject to clipping. Apply: Compare target and root dimensions before selecting full visibility. Verify: The callback can report full intersection only when geometry permits the target’s entire area inside the effective root. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
4. science dashboard: model, boundary and recovery
Create a small science dashboard using cards becoming visible in a fixed viewport. Combine “Large targets need a suitable policy” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Intersection ratio uses target area, so a long article section may never reach a high threshold in a short viewport. Apply: Measure representative geometry and use low thresholds or sentinels when appropriate. Verify: A lower ratio can create a reachable chapter-entry signal for tall sections. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. revision page: model, boundary and recovery
Create a small revision page using practice answers revealed near the learner. Combine “unobserve removes one target” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: unobserve stops observing a specified target while leaving other registrations active. Apply: Unobserve only the completed target. Verify: The loaded image stops producing entries while other images remain observed. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
6. family planner: model, boundary and recovery
Create a small family planner using infinite-list sentinels with duplicate-load protection. Combine “Lazy loading needs duplicate-work protection” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: A sentinel or image can intersect more than once as scrolling and layout change. Apply: Set a loading state or unobserve after committing the one-time action. Verify: The guard prevents repeated loads while the same target crosses boundaries again. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
7. accessible navigation: model, boundary and recovery
Create a small accessible navigation using current-section state without stealing focus. Combine “Observation is not proof of attention” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: Intersection says geometry crossed a threshold; it does not prove the tab was visible, content unobscured in every sense or a person read it. Apply: Combine explicit learner action and appropriate visibility signals for meaningful progress. Verify: The boolean is one technical observation, not a human-learning conclusion. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. browser fixture: model, boundary and recovery
Create a small browser fixture using controlled root, target and threshold assertions. Combine “The constructor fixes one configuration” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.
Explained route. Start with: One observer has one callback, root, rootMargin, scrollMargin and threshold configuration for all targets it watches. Apply: Group targets by a genuinely shared observation policy. Verify: Every target observed by this instance uses the same three thresholds. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
Frequently asked questions
How long should a practice session be?
Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.
Should every option or function be memorised?
No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.
What if the result is correct but the explanation is weak?
Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.
Is the shortest solution the best?
Not automatically. Prefer the solution whose semantics, failure modes and maintenance cost are easiest to justify for the actual project.
When should official documentation be used?
Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.
How can a parent help without technical expertise?
Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.
How do we test transfer?
Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.
What should be saved after practice?
Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.
Can these exercises replace backups?
No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.
What counts as mastery?
The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.
