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 ResizeObserver reports changes to an observed element’s size, including changes that happen without a window resize. It is an observation primitive, not a licence to perform unlimited layout writes inside a callback. Mastery means choosing the correct observed box, reading logical dimensions safely, separating measurement from mutation, preventing feedback loops, cleaning up ownership, and preferring CSS container queries when no JavaScript behaviour is actually required. 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
ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size 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 attaching only a window resize listener and missing content-driven component changes. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Resize the element without resizing the viewport and record the delivered entry.
For the ResizeObserver watches element size chapter on JavaScript ResizeObserver, 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 attaching only a window resize listener and missing content-driven component changes. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const ro=new ResizeObserver(entries=>console.log(entries.length))
ro.observe(card)Explained result. The card can trigger observation when its own box changes, regardless of the cause. 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 card. Predict the rule using a notes panel changing layout when its own width changes. 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 “ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change.” Apply this procedure: Resize the element without resizing the viewport and record the delivered entry. The expected mechanism is: The card can trigger observation when its own box changes, regardless of the cause. For the homework card, add one near-miss that exposes attaching only a window resize listener and missing content-driven component changes. 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 shelf. Contrast the rule using a virtual shelf recalculating visible labels. 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 “ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change.” Apply this procedure: Resize the element without resizing the viewport and record the delivered entry. The expected mechanism is: The card can trigger observation when its own box changes, regardless of the cause. For the library shelf, add one near-miss that exposes attaching only a window resize listener and missing content-driven component changes. 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 timetable. Stress-test the rule using a calendar component adapting inside a sidebar. 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 “ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change.” Apply this procedure: Resize the element without resizing the viewport and record the delivered entry. The expected mechanism is: The card can trigger observation when its own box changes, regardless of the cause. For the CCA timetable, add one near-miss that exposes attaching only a window resize listener and missing content-driven component changes. 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 chart. Explain the rule using a canvas redrawn at device-pixel dimensions. 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 “ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change.” Apply this procedure: Resize the element without resizing the viewport and record the delivered entry. The expected mechanism is: The card can trigger observation when its own box changes, regardless of the cause. For the science chart, add one near-miss that exposes attaching only a window resize listener and missing content-driven component changes. 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 attaching only a window resize listener and missing content-driven component changes.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Resize the element without resizing the viewport and record the delivered entry.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from ResizeObserver watches element size?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing attaching only a window resize listener and missing content-driven component changes 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 an expandable panel with content-driven height. Include one ordinary case, one boundary and one deliberate failure caused by attaching only a window resize listener and missing content-driven component changes. 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: ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change. It shows a trace, not only a final value. The ordinary case should demonstrate “The card can trigger observation when its own box changes, regardless of the cause.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Resize the element without resizing the viewport and record the delivered entry. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For ResizeObserver watches element size, separate the documented JavaScript ResizeObserver 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 browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer. 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 running getBoundingClientRect repeatedly in setInterval. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Observe the precise owner element and remove the polling loop.
For the Observation is not polling chapter on JavaScript ResizeObserver, 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 running getBoundingClientRect repeatedly in setInterval. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const ro=new ResizeObserver(handleResize)Explained result. The callback is scheduled by the observation processing model when reportable size changes exist. 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 timetable. Contrast the rule using a calendar component adapting inside a sidebar. 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 browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer.” Apply this procedure: Observe the precise owner element and remove the polling loop. The expected mechanism is: The callback is scheduled by the observation processing model when reportable size changes exist. For the CCA timetable, add one near-miss that exposes running getBoundingClientRect repeatedly in setInterval. 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 chart. Stress-test the rule using a canvas redrawn at device-pixel dimensions. 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 browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer.” Apply this procedure: Observe the precise owner element and remove the polling loop. The expected mechanism is: The callback is scheduled by the observation processing model when reportable size changes exist. For the science chart, add one near-miss that exposes running getBoundingClientRect repeatedly in setInterval. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Explain the rule using tiles responding to their container rather than 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 “the browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer.” Apply this procedure: Observe the precise owner element and remove the polling loop. The expected mechanism is: The callback is scheduled by the observation processing model when reportable size changes exist. For the revision dashboard, add one near-miss that exposes running getBoundingClientRect repeatedly in setInterval. 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 an expandable panel with content-driven height. 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 browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer.” Apply this procedure: Observe the precise owner element and remove the polling loop. The expected mechanism is: The callback is scheduled by the observation processing model when reportable size changes exist. For the family planner, add one near-miss that exposes running getBoundingClientRect repeatedly in setInterval. 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 running getBoundingClientRect repeatedly in setInterval.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Observe the precise owner element and remove the polling loop.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Observation is not polling?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing running getBoundingClientRect repeatedly in setInterval be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessibility review with layout changes that preserve reading and focus order. Include one ordinary case, one boundary and one deliberate failure caused by running getBoundingClientRect repeatedly in setInterval. 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 browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer. It shows a trace, not only a final value. The ordinary case should demonstrate “The callback is scheduled by the observation processing model when reportable size changes exist.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Observe the precise owner element and remove the polling loop. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Observation is not polling, separate the documented JavaScript ResizeObserver 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 ResizeObserverEntry connects measured box information to the exact observed target element. 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 one shared global size for every component. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Iterate entries and derive state from entry.target.
For the Each entry identifies its target chapter on JavaScript ResizeObserver, 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 one shared global size for every component. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
for(const entry of entries){ update(entry.target,entry.contentRect) }Explained result. Each component is updated from its own delivered measurement. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Stress-test the rule using tiles responding to their container rather than 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 ResizeObserverEntry connects measured box information to the exact observed target element.” Apply this procedure: Iterate entries and derive state from entry.target. The expected mechanism is: Each component is updated from its own delivered measurement. For the revision dashboard, add one near-miss that exposes using one shared global size for every component. 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 an expandable panel with content-driven height. 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 ResizeObserverEntry connects measured box information to the exact observed target element.” Apply this procedure: Iterate entries and derive state from entry.target. The expected mechanism is: Each component is updated from its own delivered measurement. For the family planner, add one near-miss that exposes using one shared global size for every component. 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: accessibility review. Transfer the rule using layout changes that preserve reading and focus order. 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 ResizeObserverEntry connects measured box information to the exact observed target element.” Apply this procedure: Iterate entries and derive state from entry.target. The expected mechanism is: Each component is updated from its own delivered measurement. For the accessibility review, add one near-miss that exposes using one shared global size for every component. 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 observed entries, cleanup and loop-error evidence. 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 ResizeObserverEntry connects measured box information to the exact observed target element.” Apply this procedure: Iterate entries and derive state from entry.target. The expected mechanism is: Each component is updated from its own delivered measurement. For the browser fixture, add one near-miss that exposes using one shared global size for every component. 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 one shared global size for every component.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Iterate entries and derive state from entry.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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Each entry identifies its target?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using one shared global size for every component 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 observed entries, cleanup and loop-error evidence. Include one ordinary case, one boundary and one deliberate failure caused by using one shared global size for every component. 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 ResizeObserverEntry connects measured box information to the exact observed target element. It shows a trace, not only a final value. The ordinary case should demonstrate “Each component is updated from its own delivered measurement.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Iterate entries and derive state from entry.target. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Each entry identifies its target, separate the documented JavaScript ResizeObserver 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is reading content width while setting a threshold defined on the outer card. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Declare the box option and test with visible padding and borders.
For the content-box and border-box are different chapter on JavaScript ResizeObserver, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on reading content width while setting a threshold defined on the outer card. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.observe(card,{box:'border-box'})Explained result. The observation tracks the card’s border-box dimensions rather than only its content area. 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: accessibility review. Explain the rule using layout changes that preserve reading and focus order. 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision.” Apply this procedure: Declare the box option and test with visible padding and borders. The expected mechanism is: The observation tracks the card’s border-box dimensions rather than only its content area. For the accessibility review, add one near-miss that exposes reading content width while setting a threshold defined on the outer card. 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 observed entries, cleanup and loop-error evidence. 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision.” Apply this procedure: Declare the box option and test with visible padding and borders. The expected mechanism is: The observation tracks the card’s border-box dimensions rather than only its content area. For the browser fixture, add one near-miss that exposes reading content width while setting a threshold defined on the outer card. 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 card. Predict the rule using a notes panel changing layout when its own width changes. 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision.” Apply this procedure: Declare the box option and test with visible padding and borders. The expected mechanism is: The observation tracks the card’s border-box dimensions rather than only its content area. For the homework card, add one near-miss that exposes reading content width while setting a threshold defined on the outer card. 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 shelf. Contrast the rule using a virtual shelf recalculating visible labels. 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision.” Apply this procedure: Declare the box option and test with visible padding and borders. The expected mechanism is: The observation tracks the card’s border-box dimensions rather than only its content area. For the library shelf, add one near-miss that exposes reading content width while setting a threshold defined on the outer card. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers reading content width while setting a threshold defined on the outer card.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Declare the box option and test with visible padding and borders.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from content-box and border-box are different?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading content width while setting a threshold defined on the outer card be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework card with a notes panel changing layout when its own width changes. Include one ordinary case, one boundary and one deliberate failure caused by reading content width while setting a threshold defined on the outer card. 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 content box excludes padding and border while the border box includes them, so the chosen observation must match the decision. It shows a trace, not only a final value. The ordinary case should demonstrate “The observation tracks the card’s border-box dimensions rather than only its content area.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Declare the box option and test with visible padding and borders. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For content-box and border-box are different, separate the documented JavaScript ResizeObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 5 OF 20 . Use the core tools
5. device-pixel-content-box serves pixel-exact work
device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores. 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 multiplying by devicePixelRatio and assuming browser rounding is always identical. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use the delivered device-pixel size when supported and keep a tested fallback.
For the device-pixel-content-box serves pixel-exact work chapter on JavaScript ResizeObserver, 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 multiplying by devicePixelRatio and assuming browser rounding is always identical. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.observe(canvas,{box:'device-pixel-content-box'})Explained result. The entry can provide integer device-pixel dimensions for the drawing buffer. 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 card. Transfer the rule using a notes panel changing layout when its own width changes. 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 “device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores.” Apply this procedure: Use the delivered device-pixel size when supported and keep a tested fallback. The expected mechanism is: The entry can provide integer device-pixel dimensions for the drawing buffer. For the homework card, add one near-miss that exposes multiplying by devicePixelRatio and assuming browser rounding is always identical. 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 shelf. Predict the rule using a virtual shelf recalculating visible labels. 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 “device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores.” Apply this procedure: Use the delivered device-pixel size when supported and keep a tested fallback. The expected mechanism is: The entry can provide integer device-pixel dimensions for the drawing buffer. For the library shelf, add one near-miss that exposes multiplying by devicePixelRatio and assuming browser rounding is always identical. 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 timetable. Contrast the rule using a calendar component adapting inside a sidebar. 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 “device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores.” Apply this procedure: Use the delivered device-pixel size when supported and keep a tested fallback. The expected mechanism is: The entry can provide integer device-pixel dimensions for the drawing buffer. For the CCA timetable, add one near-miss that exposes multiplying by devicePixelRatio and assuming browser rounding is always identical. 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 chart. Stress-test the rule using a canvas redrawn at device-pixel dimensions. 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 “device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores.” Apply this procedure: Use the delivered device-pixel size when supported and keep a tested fallback. The expected mechanism is: The entry can provide integer device-pixel dimensions for the drawing buffer. For the science chart, add one near-miss that exposes multiplying by devicePixelRatio and assuming browser rounding is always identical. 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 multiplying by devicePixelRatio and assuming browser rounding is always identical.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use the delivered device-pixel size when supported and keep a tested fallback.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from device-pixel-content-box serves pixel-exact work?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing multiplying by devicePixelRatio and assuming browser rounding is always identical be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library shelf with a virtual shelf recalculating visible labels. Include one ordinary case, one boundary and one deliberate failure caused by multiplying by devicePixelRatio and assuming browser rounding is always identical. 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: device-pixel-content-box reports content dimensions in device pixels before CSS transforms, useful for sharp canvas backing stores. It shows a trace, not only a final value. The ordinary case should demonstrate “The entry can provide integer device-pixel dimensions for the drawing buffer.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use the delivered device-pixel size when supported and keep a tested fallback. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For device-pixel-content-box serves pixel-exact work, separate the documented JavaScript ResizeObserver 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
inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode. 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 hard-coding width as the only meaningful responsive dimension. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose logical or physical measurements according to the component contract.
For the Logical sizes respect writing mode chapter on JavaScript ResizeObserver, 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 hard-coding width as the only meaningful responsive dimension. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const {inlineSize,blockSize}=entry.borderBoxSize[0]Explained result. The values follow the element’s writing mode and describe its inline and block axes. 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 timetable. Predict the rule using a calendar component adapting inside a sidebar. 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 “inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode.” Apply this procedure: Choose logical or physical measurements according to the component contract. The expected mechanism is: The values follow the element’s writing mode and describe its inline and block axes. For the CCA timetable, add one near-miss that exposes hard-coding width as the only meaningful responsive dimension. 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 chart. Contrast the rule using a canvas redrawn at device-pixel dimensions. 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 “inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode.” Apply this procedure: Choose logical or physical measurements according to the component contract. The expected mechanism is: The values follow the element’s writing mode and describe its inline and block axes. For the science chart, add one near-miss that exposes hard-coding width as the only meaningful responsive dimension. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Stress-test the rule using tiles responding to their container rather than 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 “inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode.” Apply this procedure: Choose logical or physical measurements according to the component contract. The expected mechanism is: The values follow the element’s writing mode and describe its inline and block axes. For the revision dashboard, add one near-miss that exposes hard-coding width as the only meaningful responsive dimension. 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 an expandable panel with content-driven height. 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 “inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode.” Apply this procedure: Choose logical or physical measurements according to the component contract. The expected mechanism is: The values follow the element’s writing mode and describe its inline and block axes. For the family planner, add one near-miss that exposes hard-coding width as the only meaningful responsive dimension. 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 hard-coding width as the only meaningful responsive dimension.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Choose logical or physical measurements according to the component contract.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Logical sizes respect writing mode?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing hard-coding width as the only meaningful responsive dimension be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA timetable with a calendar component adapting inside a sidebar. Include one ordinary case, one boundary and one deliberate failure caused by hard-coding width as the only meaningful responsive dimension. 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: inlineSize and blockSize describe logical axes, which may not equal physical width and height in every writing mode. It shows a trace, not only a final value. The ordinary case should demonstrate “The values follow the element’s writing mode and describe its inline and block axes.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Choose logical or physical measurements according to the component contract. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Logical sizes respect writing mode, separate the documented JavaScript ResizeObserver 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 specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one. 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 a plain object in every browser and environment. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Feature-test, read the first fragment deliberately, and document unsupported fragmentation.
For the Box-size members are sequence-like chapter on JavaScript ResizeObserver, 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 a plain object in every browser and environment. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const size=entry.borderBoxSize?.[0]Explained result. The code accesses the first reported box fragment rather than treating the sequence as a scalar. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Contrast the rule using tiles responding to their container rather than 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 “the specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one.” Apply this procedure: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. The expected mechanism is: The code accesses the first reported box fragment rather than treating the sequence as a scalar. For the revision dashboard, add one near-miss that exposes assuming a plain object in every browser and environment. 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 an expandable panel with content-driven height. 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 specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one.” Apply this procedure: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. The expected mechanism is: The code accesses the first reported box fragment rather than treating the sequence as a scalar. For the family planner, add one near-miss that exposes assuming a plain object in every browser and environment. 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: accessibility review. Explain the rule using layout changes that preserve reading and focus order. 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 specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one.” Apply this procedure: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. The expected mechanism is: The code accesses the first reported box fragment rather than treating the sequence as a scalar. For the accessibility review, add one near-miss that exposes assuming a plain object in every browser and environment. 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 observed entries, cleanup and loop-error evidence. 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 specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one.” Apply this procedure: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. The expected mechanism is: The code accesses the first reported box fragment rather than treating the sequence as a scalar. For the browser fixture, add one near-miss that exposes assuming a plain object in every browser and environment. 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 a plain object in every browser and environment.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Feature-test, read the first fragment deliberately, and document unsupported fragmentation.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Box-size members are sequence-like?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming a plain object in every browser and environment be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science chart with a canvas redrawn at device-pixel dimensions. Include one ordinary case, one boundary and one deliberate failure caused by assuming a plain object in every browser and environment. 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 specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one. It shows a trace, not only a final value. The ordinary case should demonstrate “The code accesses the first reported box fragment rather than treating the sequence as a scalar.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Box-size members are sequence-like, separate the documented JavaScript ResizeObserver 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
contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions. 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 mixing contentRect width with a border-box threshold. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Label each measurement source and keep threshold units consistent.
For the contentRect is a compatibility surface chapter on JavaScript ResizeObserver, 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 mixing contentRect width with a border-box threshold. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
const width=entry.borderBoxSize?.[0]?.inlineSize ?? entry.contentRect.widthExplained result. The fallback still measures content width, so design thresholds must account for the semantic difference. 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: accessibility review. Stress-test the rule using layout changes that preserve reading and focus order. 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 “contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions.” Apply this procedure: Label each measurement source and keep threshold units consistent. The expected mechanism is: The fallback still measures content width, so design thresholds must account for the semantic difference. For the accessibility review, add one near-miss that exposes mixing contentRect width with a border-box threshold. 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 observed entries, cleanup and loop-error evidence. 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 “contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions.” Apply this procedure: Label each measurement source and keep threshold units consistent. The expected mechanism is: The fallback still measures content width, so design thresholds must account for the semantic difference. For the browser fixture, add one near-miss that exposes mixing contentRect width with a border-box threshold. 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 card. Transfer the rule using a notes panel changing layout when its own width changes. 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 “contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions.” Apply this procedure: Label each measurement source and keep threshold units consistent. The expected mechanism is: The fallback still measures content width, so design thresholds must account for the semantic difference. For the homework card, add one near-miss that exposes mixing contentRect width with a border-box threshold. 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 shelf. Predict the rule using a virtual shelf recalculating visible labels. 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 “contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions.” Apply this procedure: Label each measurement source and keep threshold units consistent. The expected mechanism is: The fallback still measures content width, so design thresholds must account for the semantic difference. For the library shelf, add one near-miss that exposes mixing contentRect width with a border-box threshold. 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 mixing contentRect width with a border-box threshold.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Label each measurement source and keep threshold units consistent.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from contentRect is a compatibility surface?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mixing contentRect width with a border-box threshold be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision dashboard with tiles responding to their container rather than viewport. Include one ordinary case, one boundary and one deliberate failure caused by mixing contentRect width with a border-box threshold. 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: contentRect provides a rectangle for the content area and remains useful as a fallback, while box-size members express modern logical dimensions. It shows a trace, not only a final value. The ordinary case should demonstrate “The fallback still measures content width, so design thresholds must account for the semantic difference.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Label each measurement source and keep threshold units consistent. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For contentRect is a compatibility surface, separate the documented JavaScript ResizeObserver 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
observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is waiting only for a later user resize before initialising behaviour. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Make the callback idempotent and test the first delivery explicitly.
For the Initial observation can produce a delivery chapter on JavaScript ResizeObserver, 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 waiting only for a later user resize before initialising behaviour. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.observe(panel)Explained result. The first delivered entry can initialise the component from its current size. 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 card. Explain the rule using a notes panel changing layout when its own width changes. 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 “observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state.” Apply this procedure: Make the callback idempotent and test the first delivery explicitly. The expected mechanism is: The first delivered entry can initialise the component from its current size. For the homework card, add one near-miss that exposes waiting only for a later user resize before initialising behaviour. 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 shelf. Transfer the rule using a virtual shelf recalculating visible labels. 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 “observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state.” Apply this procedure: Make the callback idempotent and test the first delivery explicitly. The expected mechanism is: The first delivered entry can initialise the component from its current size. For the library shelf, add one near-miss that exposes waiting only for a later user resize before initialising behaviour. 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 timetable. Predict the rule using a calendar component adapting inside a sidebar. 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 “observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state.” Apply this procedure: Make the callback idempotent and test the first delivery explicitly. The expected mechanism is: The first delivered entry can initialise the component from its current size. For the CCA timetable, add one near-miss that exposes waiting only for a later user resize before initialising behaviour. 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 chart. Contrast the rule using a canvas redrawn at device-pixel dimensions. 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 “observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state.” Apply this procedure: Make the callback idempotent and test the first delivery explicitly. The expected mechanism is: The first delivered entry can initialise the component from its current size. For the science chart, add one near-miss that exposes waiting only for a later user resize before initialising behaviour. 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 waiting only for a later user resize before initialising behaviour.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Make the callback idempotent and test the first delivery explicitly.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Initial observation can produce a delivery?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing waiting only for a later user resize before initialising behaviour 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 an expandable panel with content-driven height. Include one ordinary case, one boundary and one deliberate failure caused by waiting only for a later user resize before initialising behaviour. 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: observing a rendered nonzero element commonly leads to an initial report so the component can establish its first measured state. It shows a trace, not only a final value. The ordinary case should demonstrate “The first delivered entry can initialise the component from its current size.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Make the callback idempotent and test the first delivery explicitly. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Initial observation can produce a delivery, separate the documented JavaScript ResizeObserver 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
elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested. 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 an invisible display:none panel keeps its previous measured size contract. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Exercise show, hide, detach and reattach cases in a disposable fixture.
For the Display and connectivity affect observation chapter on JavaScript ResizeObserver, 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 an invisible display:none panel keeps its previous measured size contract. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
panel.hidden=trueExplained result. The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. 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 timetable. Transfer the rule using a calendar component adapting inside a sidebar. 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 “elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested.” Apply this procedure: Exercise show, hide, detach and reattach cases in a disposable fixture. The expected mechanism is: The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. For the CCA timetable, add one near-miss that exposes assuming an invisible display:none panel keeps its previous measured size contract. 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 chart. Predict the rule using a canvas redrawn at device-pixel dimensions. 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 “elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested.” Apply this procedure: Exercise show, hide, detach and reattach cases in a disposable fixture. The expected mechanism is: The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. For the science chart, add one near-miss that exposes assuming an invisible display:none panel keeps its previous measured size contract. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Contrast the rule using tiles responding to their container rather than 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 “elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested.” Apply this procedure: Exercise show, hide, detach and reattach cases in a disposable fixture. The expected mechanism is: The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. For the revision dashboard, add one near-miss that exposes assuming an invisible display:none panel keeps its previous measured size contract. 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 an expandable panel with content-driven height. 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 “elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested.” Apply this procedure: Exercise show, hide, detach and reattach cases in a disposable fixture. The expected mechanism is: The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. For the family planner, add one near-miss that exposes assuming an invisible display:none panel keeps its previous measured size contract. 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 an invisible display:none panel keeps its previous measured size contract.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Exercise show, hide, detach and reattach cases in a disposable fixture.” and record the first changed observation.
- Transfer check: repeat the rule in a second context and identify what remains invariant.
A parent does not need to know the final JavaScript ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Display and connectivity affect observation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming an invisible display:none panel keeps its previous measured size contract be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessibility review with layout changes that preserve reading and focus order. Include one ordinary case, one boundary and one deliberate failure caused by assuming an invisible display:none panel keeps its previous measured size contract. 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: elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested. It shows a trace, not only a final value. The ordinary case should demonstrate “The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Exercise show, hide, detach and reattach cases in a disposable fixture. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Display and connectivity affect observation, separate the documented JavaScript ResizeObserver 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
measurement callbacks that immediately change the measured size can trigger another observation cycle. 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 toggling width inside the callback until the browser reports a loop error. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Read all entries first, compute decisions, then schedule bounded writes for a later frame.
For the Callbacks need a read-then-write plan chapter on JavaScript ResizeObserver, 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 toggling width inside the callback until the browser reports a loop error. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
requestAnimationFrame(()=>card.classList.toggle('compact',small))Explained result. The class write is separated from the delivered measurement and should be guarded against no-op repetition. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Predict the rule using tiles responding to their container rather than 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 “measurement callbacks that immediately change the measured size can trigger another observation cycle.” Apply this procedure: Read all entries first, compute decisions, then schedule bounded writes for a later frame. The expected mechanism is: The class write is separated from the delivered measurement and should be guarded against no-op repetition. For the revision dashboard, add one near-miss that exposes toggling width inside the callback until the browser reports a loop error. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 2: family planner. Contrast the rule using an expandable panel with content-driven height. 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 “measurement callbacks that immediately change the measured size can trigger another observation cycle.” Apply this procedure: Read all entries first, compute decisions, then schedule bounded writes for a later frame. The expected mechanism is: The class write is separated from the delivered measurement and should be guarded against no-op repetition. For the family planner, add one near-miss that exposes toggling width inside the callback until the browser reports a loop error. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: accessibility review. Stress-test the rule using layout changes that preserve reading and focus order. 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 “measurement callbacks that immediately change the measured size can trigger another observation cycle.” Apply this procedure: Read all entries first, compute decisions, then schedule bounded writes for a later frame. The expected mechanism is: The class write is separated from the delivered measurement and should be guarded against no-op repetition. For the accessibility review, add one near-miss that exposes toggling width inside the callback until the browser reports a loop error. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 4: browser fixture. Explain the rule using observed entries, cleanup and loop-error evidence. 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 “measurement callbacks that immediately change the measured size can trigger another observation cycle.” Apply this procedure: Read all entries first, compute decisions, then schedule bounded writes for a later frame. The expected mechanism is: The class write is separated from the delivered measurement and should be guarded against no-op repetition. For the browser fixture, add one near-miss that exposes toggling width inside the callback until the browser reports a loop error. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Diagnostic route
- Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
- Boundary check: create the smallest input that triggers toggling width inside the callback until the browser reports a loop error.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Read all entries first, compute decisions, then schedule bounded writes for a later frame.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Callbacks need a read-then-write plan?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing toggling width inside the callback until the browser reports a loop error 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 observed entries, cleanup and loop-error evidence. Include one ordinary case, one boundary and one deliberate failure caused by toggling width inside the callback until the browser reports a loop error. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: measurement callbacks that immediately change the measured size can trigger another observation cycle. It shows a trace, not only a final value. The ordinary case should demonstrate “The class write is separated from the delivered measurement and should be guarded against no-op repetition.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Read all entries first, compute decisions, then schedule bounded writes for a later frame. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Callbacks need a read-then-write plan, separate the documented JavaScript ResizeObserver 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is suppressing the error without removing the feedback relationship. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Trace which write changes which observed box and make the state transition converge.
For the Resize loops are a design signal chapter on JavaScript ResizeObserver, 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 suppressing the error without removing the feedback relationship. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
window.addEventListener('error',e=>console.log(e.message))Explained result. The error is evidence of undelivered cyclic observations, not simply a message to hide. 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: accessibility review. Contrast the rule using layout changes that preserve reading and focus order. 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes.” Apply this procedure: Trace which write changes which observed box and make the state transition converge. The expected mechanism is: The error is evidence of undelivered cyclic observations, not simply a message to hide. For the accessibility review, add one near-miss that exposes suppressing the error without removing the feedback relationship. 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 observed entries, cleanup and loop-error evidence. 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes.” Apply this procedure: Trace which write changes which observed box and make the state transition converge. The expected mechanism is: The error is evidence of undelivered cyclic observations, not simply a message to hide. For the browser fixture, add one near-miss that exposes suppressing the error without removing the feedback relationship. 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 card. Explain the rule using a notes panel changing layout when its own width changes. 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes.” Apply this procedure: Trace which write changes which observed box and make the state transition converge. The expected mechanism is: The error is evidence of undelivered cyclic observations, not simply a message to hide. For the homework card, add one near-miss that exposes suppressing the error without removing the feedback relationship. 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 shelf. Transfer the rule using a virtual shelf recalculating visible labels. 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes.” Apply this procedure: Trace which write changes which observed box and make the state transition converge. The expected mechanism is: The error is evidence of undelivered cyclic observations, not simply a message to hide. For the library shelf, add one near-miss that exposes suppressing the error without removing the feedback relationship. 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 suppressing the error without removing the feedback relationship.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Trace which write changes which observed box and make the state transition converge.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Resize loops are a design signal?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing suppressing the error without removing the feedback relationship be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework card with a notes panel changing layout when its own width changes. Include one ordinary case, one boundary and one deliberate failure caused by suppressing the error without removing the feedback relationship. 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 processing model can defer observations and deliver a resize-loop error when callbacks cause cyclic size changes. It shows a trace, not only a final value. The ordinary case should demonstrate “The error is evidence of undelivered cyclic observations, not simply a message to hide.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Trace which write changes which observed box and make the state transition converge. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Resize loops are a design signal, separate the documented JavaScript ResizeObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
a component can oscillate when one layout state changes width across the same threshold that selected 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 switching at exactly one boundary in both directions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension.
For the Use hysteresis near thresholds chapter on JavaScript ResizeObserver, 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 switching at exactly one boundary in both directions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
if(!compact && w<380) compact=true; else if(compact && w>400) compact=false;Explained result. The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. 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 card. Stress-test the rule using a notes panel changing layout when its own width changes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a component can oscillate when one layout state changes width across the same threshold that selected it.” Apply this procedure: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. The expected mechanism is: The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. For the homework card, add one near-miss that exposes switching at exactly one boundary in both directions. 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 shelf. Explain the rule using a virtual shelf recalculating visible labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a component can oscillate when one layout state changes width across the same threshold that selected it.” Apply this procedure: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. The expected mechanism is: The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. For the library shelf, add one near-miss that exposes switching at exactly one boundary in both directions. 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 timetable. Transfer the rule using a calendar component adapting inside a sidebar. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a component can oscillate when one layout state changes width across the same threshold that selected it.” Apply this procedure: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. The expected mechanism is: The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. For the CCA timetable, add one near-miss that exposes switching at exactly one boundary in both directions. 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 chart. Predict the rule using a canvas redrawn at device-pixel dimensions. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a component can oscillate when one layout state changes width across the same threshold that selected it.” Apply this procedure: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. The expected mechanism is: The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. For the science chart, add one near-miss that exposes switching at exactly one boundary in both directions. 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 switching at exactly one boundary in both directions.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Use hysteresis near thresholds?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing switching at exactly one boundary in both directions be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny library shelf with a virtual shelf recalculating visible labels. Include one ordinary case, one boundary and one deliberate failure caused by switching at exactly one boundary in both directions. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: a component can oscillate when one layout state changes width across the same threshold that selected it. It shows a trace, not only a final value. The ordinary case should demonstrate “The twenty-pixel band prevents rapid back-and-forth state changes near the boundary.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Use hysteresis near thresholds, separate the documented JavaScript ResizeObserver 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 single ResizeObserver may observe multiple elements and deliver several entries together. 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 an untracked observer per card and leaking ownership. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep one observer per component system and a mapping from target to state.
For the One observer can own many targets chapter on JavaScript ResizeObserver, 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 an untracked observer per card and leaking ownership. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
cards.forEach(card=>ro.observe(card))Explained result. The callback can process a batch while shared lifecycle code owns observation. 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 timetable. Explain the rule using a calendar component adapting inside a sidebar. 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 single ResizeObserver may observe multiple elements and deliver several entries together.” Apply this procedure: Keep one observer per component system and a mapping from target to state. The expected mechanism is: The callback can process a batch while shared lifecycle code owns observation. For the CCA timetable, add one near-miss that exposes creating an untracked observer per card and leaking ownership. 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 chart. Transfer the rule using a canvas redrawn at device-pixel dimensions. 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 single ResizeObserver may observe multiple elements and deliver several entries together.” Apply this procedure: Keep one observer per component system and a mapping from target to state. The expected mechanism is: The callback can process a batch while shared lifecycle code owns observation. For the science chart, add one near-miss that exposes creating an untracked observer per card and leaking ownership. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Predict the rule using tiles responding to their container rather than 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 single ResizeObserver may observe multiple elements and deliver several entries together.” Apply this procedure: Keep one observer per component system and a mapping from target to state. The expected mechanism is: The callback can process a batch while shared lifecycle code owns observation. For the revision dashboard, add one near-miss that exposes creating an untracked observer per card and leaking ownership. 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 an expandable panel with content-driven height. 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 single ResizeObserver may observe multiple elements and deliver several entries together.” Apply this procedure: Keep one observer per component system and a mapping from target to state. The expected mechanism is: The callback can process a batch while shared lifecycle code owns observation. For the family planner, add one near-miss that exposes creating an untracked observer per card and leaking ownership. 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 an untracked observer per card and leaking ownership.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep one observer per component system and a mapping from target to 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from One observer can own many targets?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing creating an untracked observer per card and leaking ownership be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny CCA timetable with a calendar component adapting inside a sidebar. Include one ordinary case, one boundary and one deliberate failure caused by creating an untracked observer per card and leaking ownership. 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 single ResizeObserver may observe multiple elements and deliver several entries together. It shows a trace, not only a final value. The ordinary case should demonstrate “The callback can process a batch while shared lifecycle code owns observation.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep one observer per component system and a mapping from target to state. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For One observer can own many targets, separate the documented JavaScript ResizeObserver 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 watching a specified element while leaving other observations 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 disconnecting a shared observer when only one card is removed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Call unobserve during that target’s teardown.
For the unobserve releases one target chapter on JavaScript ResizeObserver, 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 disconnecting a shared observer when only one card is removed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.unobserve(card)Explained result. Other elements registered with the same observer continue to be 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: revision dashboard. Transfer the rule using tiles responding to their container rather than 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 watching a specified element while leaving other observations active.” Apply this procedure: Call unobserve during that target’s teardown. The expected mechanism is: Other elements registered with the same observer continue to be observed. For the revision dashboard, add one near-miss that exposes disconnecting a shared observer when only one card is removed. 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 an expandable panel with content-driven height. 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 watching a specified element while leaving other observations active.” Apply this procedure: Call unobserve during that target’s teardown. The expected mechanism is: Other elements registered with the same observer continue to be observed. For the family planner, add one near-miss that exposes disconnecting a shared observer when only one card is removed. 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: accessibility review. Contrast the rule using layout changes that preserve reading and focus order. 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 watching a specified element while leaving other observations active.” Apply this procedure: Call unobserve during that target’s teardown. The expected mechanism is: Other elements registered with the same observer continue to be observed. For the accessibility review, add one near-miss that exposes disconnecting a shared observer when only one card is removed. 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 observed entries, cleanup and loop-error evidence. 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 watching a specified element while leaving other observations active.” Apply this procedure: Call unobserve during that target’s teardown. The expected mechanism is: Other elements registered with the same observer continue to be observed. For the browser fixture, add one near-miss that exposes disconnecting a shared observer when only one card is removed. 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 disconnecting a shared observer when only one card is removed.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Call unobserve during that target’s 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from unobserve releases one target?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing disconnecting a shared observer when only one card is removed be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny science chart with a canvas redrawn at device-pixel dimensions. Include one ordinary case, one boundary and one deliberate failure caused by disconnecting a shared observer when only one card is removed. 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 watching a specified element while leaving other observations active. It shows a trace, not only a final value. The ordinary case should demonstrate “Other elements registered with the same observer continue to be observed.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Call unobserve during that target’s teardown. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For unobserve releases one target, separate the documented JavaScript ResizeObserver 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 removes all observation targets from that ResizeObserver. 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 dropping the JavaScript variable and assuming every observer relationship ends immediately. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Call disconnect when the owning component system is destroyed.
For the disconnect releases every target chapter on JavaScript ResizeObserver, 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 dropping the JavaScript variable and assuming every observer relationship ends immediately. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.disconnect()Explained result. The observer no longer watches any of its former targets. 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: accessibility review. Predict the rule using layout changes that preserve reading and focus order. 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 removes all observation targets from that ResizeObserver.” Apply this procedure: Call disconnect when the owning component system is destroyed. The expected mechanism is: The observer no longer watches any of its former targets. For the accessibility review, add one near-miss that exposes dropping the JavaScript variable and assuming every observer relationship ends immediately. 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 observed entries, cleanup and loop-error evidence. 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 removes all observation targets from that ResizeObserver.” Apply this procedure: Call disconnect when the owning component system is destroyed. The expected mechanism is: The observer no longer watches any of its former targets. For the browser fixture, add one near-miss that exposes dropping the JavaScript variable and assuming every observer relationship ends immediately. 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 card. Stress-test the rule using a notes panel changing layout when its own width changes. 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 removes all observation targets from that ResizeObserver.” Apply this procedure: Call disconnect when the owning component system is destroyed. The expected mechanism is: The observer no longer watches any of its former targets. For the homework card, add one near-miss that exposes dropping the JavaScript variable and assuming every observer relationship ends immediately. 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 shelf. Explain the rule using a virtual shelf recalculating visible labels. 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 removes all observation targets from that ResizeObserver.” Apply this procedure: Call disconnect when the owning component system is destroyed. The expected mechanism is: The observer no longer watches any of its former targets. For the library shelf, add one near-miss that exposes dropping the JavaScript variable and assuming every observer relationship ends immediately. 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 dropping the JavaScript variable and assuming every observer relationship ends immediately.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Call disconnect when the owning component system is destroyed.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from disconnect releases every target?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing dropping the JavaScript variable and assuming every observer relationship ends immediately be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny revision dashboard with tiles responding to their container rather than viewport. Include one ordinary case, one boundary and one deliberate failure caused by dropping the JavaScript variable and assuming every observer relationship ends immediately. 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 removes all observation targets from that ResizeObserver. It shows a trace, not only a final value. The ordinary case should demonstrate “The observer no longer watches any of its former targets.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Call disconnect when the owning component system is destroyed. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For disconnect releases every target, separate the documented JavaScript ResizeObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 17 OF 20 . Transfer with judgment
17. CSS container queries may own pure styling
when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.
The high-value mistake in this chapter is using ResizeObserver to add classes for a layout CSS can describe directly. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Separate visual styling from imperative work such as canvas redraw or data calculation.
For the CSS container queries may own pure styling chapter on JavaScript ResizeObserver, 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 ResizeObserver to add classes for a layout CSS can describe directly. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
@container (inline-size > 30rem){.card{display:grid}}Explained result. CSS owns the presentation threshold while JavaScript remains unnecessary for that case. 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 card. Contrast the rule using a notes panel changing layout when its own width changes. 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 “when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state.” Apply this procedure: Separate visual styling from imperative work such as canvas redraw or data calculation. The expected mechanism is: CSS owns the presentation threshold while JavaScript remains unnecessary for that case. For the homework card, add one near-miss that exposes using ResizeObserver to add classes for a layout CSS can describe directly. 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 shelf. Stress-test the rule using a virtual shelf recalculating visible labels. 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 “when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state.” Apply this procedure: Separate visual styling from imperative work such as canvas redraw or data calculation. The expected mechanism is: CSS owns the presentation threshold while JavaScript remains unnecessary for that case. For the library shelf, add one near-miss that exposes using ResizeObserver to add classes for a layout CSS can describe directly. 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 timetable. Explain the rule using a calendar component adapting inside a sidebar. 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 “when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state.” Apply this procedure: Separate visual styling from imperative work such as canvas redraw or data calculation. The expected mechanism is: CSS owns the presentation threshold while JavaScript remains unnecessary for that case. For the CCA timetable, add one near-miss that exposes using ResizeObserver to add classes for a layout CSS can describe directly. 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 chart. Transfer the rule using a canvas redrawn at device-pixel dimensions. 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 “when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state.” Apply this procedure: Separate visual styling from imperative work such as canvas redraw or data calculation. The expected mechanism is: CSS owns the presentation threshold while JavaScript remains unnecessary for that case. For the science chart, add one near-miss that exposes using ResizeObserver to add classes for a layout CSS can describe directly. 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 ResizeObserver to add classes for a layout CSS can describe directly.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Separate visual styling from imperative work such as canvas redraw or data calculation.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from CSS container queries may own pure styling?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using ResizeObserver to add classes for a layout CSS can describe directly 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 an expandable panel with content-driven height. Include one ordinary case, one boundary and one deliberate failure caused by using ResizeObserver to add classes for a layout CSS can describe directly. 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: when the response is only CSS presentation based on container size, container queries usually express the rule without JavaScript measurement state. It shows a trace, not only a final value. The ordinary case should demonstrate “CSS owns the presentation threshold while JavaScript remains unnecessary for that case.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Separate visual styling from imperative work such as canvas redraw or data calculation. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For CSS container queries may own pure styling, separate the documented JavaScript ResizeObserver 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. Viewport observation solves a different job
ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations. 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 choosing an observer by name rather than by the evidence needed. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write the sensed event—size, visibility or mutation—before selecting the API.
For the Viewport observation solves a different job chapter on JavaScript ResizeObserver, 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 choosing an observer by name rather than by the evidence needed. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
// size -> ResizeObserverExplained result. The API choice follows the state change the application must detect. 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 timetable. Stress-test the rule using a calendar component adapting inside a sidebar. 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 “ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations.” Apply this procedure: Write the sensed event—size, visibility or mutation—before selecting the API. The expected mechanism is: The API choice follows the state change the application must detect. For the CCA timetable, add one near-miss that exposes choosing an observer by name rather than by the evidence needed. 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 chart. Explain the rule using a canvas redrawn at device-pixel dimensions. 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 “ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations.” Apply this procedure: Write the sensed event—size, visibility or mutation—before selecting the API. The expected mechanism is: The API choice follows the state change the application must detect. For the science chart, add one near-miss that exposes choosing an observer by name rather than by the evidence needed. The answer is complete only when it says why the near-miss fails and how the corrected model transfers to a different project without relying on the original variable names.
Case 3: revision dashboard. Transfer the rule using tiles responding to their container rather than 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 “ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations.” Apply this procedure: Write the sensed event—size, visibility or mutation—before selecting the API. The expected mechanism is: The API choice follows the state change the application must detect. For the revision dashboard, add one near-miss that exposes choosing an observer by name rather than by the evidence needed. 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 an expandable panel with content-driven height. 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 “ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations.” Apply this procedure: Write the sensed event—size, visibility or mutation—before selecting the API. The expected mechanism is: The API choice follows the state change the application must detect. For the family planner, add one near-miss that exposes choosing an observer by name rather than by the evidence needed. 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 choosing an observer by name rather than by the evidence needed.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Write the sensed event—size, visibility or mutation—before selecting the API.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Viewport observation solves a different job?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing choosing an observer by name rather than by the evidence needed be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny accessibility review with layout changes that preserve reading and focus order. Include one ordinary case, one boundary and one deliberate failure caused by choosing an observer by name rather than by the evidence needed. 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: ResizeObserver measures size; IntersectionObserver reports intersection with a root; MutationObserver reports DOM mutations. It shows a trace, not only a final value. The ordinary case should demonstrate “The API choice follows the state change the application must detect.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Write the sensed event—size, visibility or mutation—before selecting the API. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Viewport observation solves a different job, separate the documented JavaScript ResizeObserver mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.
Previous chapter . Contents . Next chapter
CHAPTER 19 OF 20 . Transfer with judgment
19. Accessibility survives when semantics stay stable
visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus. 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 focus or duplicating content whenever a card crosses a width threshold. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep semantic source order stable and test keyboard and zoom behaviour.
For the Accessibility survives when semantics stay stable chapter on JavaScript ResizeObserver, 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 focus or duplicating content whenever a card crosses a width threshold. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
card.dataset.layout = small ? 'compact' : 'wide'Explained result. A layout state can change presentation without replacing the user’s active element. Check the boundary as well as the happy path: ask what happens with an empty input, a duplicate or tied value, an unsupported type, a missing path, a NULL, or a second reference to the same object. Only the relevant boundary should be kept; the list is a prompt for judgment, not a demand to force every case into every example.
Four purposeful transfer cases
Case 1: revision dashboard. Explain the rule using tiles responding to their container rather than 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 “visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus.” Apply this procedure: Keep semantic source order stable and test keyboard and zoom behaviour. The expected mechanism is: A layout state can change presentation without replacing the user’s active element. For the revision dashboard, add one near-miss that exposes moving focus or duplicating content whenever a card crosses a width threshold. 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 an expandable panel with content-driven height. 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 “visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus.” Apply this procedure: Keep semantic source order stable and test keyboard and zoom behaviour. The expected mechanism is: A layout state can change presentation without replacing the user’s active element. For the family planner, add one near-miss that exposes moving focus or duplicating content whenever a card crosses a width threshold. 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: accessibility review. Predict the rule using layout changes that preserve reading and focus order. 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 “visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus.” Apply this procedure: Keep semantic source order stable and test keyboard and zoom behaviour. The expected mechanism is: A layout state can change presentation without replacing the user’s active element. For the accessibility review, add one near-miss that exposes moving focus or duplicating content whenever a card crosses a width threshold. 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 observed entries, cleanup and loop-error evidence. 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 “visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus.” Apply this procedure: Keep semantic source order stable and test keyboard and zoom behaviour. The expected mechanism is: A layout state can change presentation without replacing the user’s active element. For the browser fixture, add one near-miss that exposes moving focus or duplicating content whenever a card crosses a width threshold. 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 focus or duplicating content whenever a card crosses a width threshold.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Keep semantic source order stable and test keyboard and zoom behaviour.” 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from Accessibility survives when semantics stay stable?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing moving focus or duplicating content whenever a card crosses a width threshold 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 observed entries, cleanup and loop-error evidence. Include one ordinary case, one boundary and one deliberate failure caused by moving focus or duplicating content whenever a card crosses a width threshold. 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: visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus. It shows a trace, not only a final value. The ordinary case should demonstrate “A layout state can change presentation without replacing the user’s active element.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Keep semantic source order stable and test keyboard and zoom behaviour. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For Accessibility survives when semantics stay stable, separate the documented JavaScript ResizeObserver 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. A browser fixture proves lifecycle and convergence
a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup. 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 approving one drag-resize screenshot. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Assert target identity, chosen box values, bounded callback count and no reports after teardown.
For the A browser fixture proves lifecycle and convergence chapter on JavaScript ResizeObserver, 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 approving one drag-resize screenshot. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.
Core worked example
ro.disconnect(); resizeHost(); await nextFrame(); assert(count===before)Explained result. No later callback should be attributed to the disconnected observer after the fixture settles. 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: accessibility review. Transfer the rule using layout changes that preserve reading and focus order. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup.” Apply this procedure: Assert target identity, chosen box values, bounded callback count and no reports after teardown. The expected mechanism is: No later callback should be attributed to the disconnected observer after the fixture settles. For the accessibility review, add one near-miss that exposes approving one drag-resize screenshot. 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 observed entries, cleanup and loop-error evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup.” Apply this procedure: Assert target identity, chosen box values, bounded callback count and no reports after teardown. The expected mechanism is: No later callback should be attributed to the disconnected observer after the fixture settles. For the browser fixture, add one near-miss that exposes approving one drag-resize screenshot. 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 card. Contrast the rule using a notes panel changing layout when its own width changes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup.” Apply this procedure: Assert target identity, chosen box values, bounded callback count and no reports after teardown. The expected mechanism is: No later callback should be attributed to the disconnected observer after the fixture settles. For the homework card, add one near-miss that exposes approving one drag-resize screenshot. 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 shelf. Stress-test the rule using a virtual shelf recalculating visible labels. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.
Reasoned route. Begin with “a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup.” Apply this procedure: Assert target identity, chosen box values, bounded callback count and no reports after teardown. The expected mechanism is: No later callback should be attributed to the disconnected observer after the fixture settles. For the library shelf, add one near-miss that exposes approving one drag-resize screenshot. 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 approving one drag-resize screenshot.
- Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
- Repair check: use the reversible procedure “Assert target identity, chosen box values, bounded callback count and no reports after 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 ResizeObserver syntax. For this chapter, useful prompts are: “What did you expect from A browser fixture proves lifecycle and convergence?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing approving one drag-resize screenshot be made smaller?” The learner, not the parent, should supply the technical explanation.
Practice with an explained answer
Question. Build a tiny homework card with a notes panel changing layout when its own width changes. Include one ordinary case, one boundary and one deliberate failure caused by approving one drag-resize screenshot. Predict each result before using a tool, then report the first point where observation differs from prediction.
Answer guide. A strong response starts with the rule: a complete test changes content, container width, padding, visibility and device scale while recording entries, state writes and cleanup. It shows a trace, not only a final value. The ordinary case should demonstrate “No later callback should be attributed to the disconnected observer after the fixture settles.” The boundary must exercise the same mechanism at an edge, and the deliberate failure must be repaired with: Assert target identity, chosen box values, bounded callback count and no reports after teardown. Other data choices are valid when the evidence supports the same causal chain.
Decision and transfer
For A browser fixture proves lifecycle and convergence, separate the documented JavaScript ResizeObserver 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 card: model, boundary and recovery
Create a small homework card using a notes panel changing layout when its own width changes. Combine “ResizeObserver watches element size” 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: ResizeObserver invokes a callback with entries when an observed Element or SVGElement has a relevant size change. Apply: Resize the element without resizing the viewport and record the delivered entry. Verify: The card can trigger observation when its own box changes, regardless of the cause. 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 shelf: model, boundary and recovery
Create a small library shelf using a virtual shelf recalculating visible labels. Combine “content-box and border-box are different” 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: the content box excludes padding and border while the border box includes them, so the chosen observation must match the decision. Apply: Declare the box option and test with visible padding and borders. Verify: The observation tracks the card’s border-box dimensions rather than only its content area. 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 timetable: model, boundary and recovery
Create a small CCA timetable using a calendar component adapting inside a sidebar. Combine “Box-size members are sequence-like” 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: the specification exposes box-size data as sequences because fragmented layout can require more than one size record, even though common cases have one. Apply: Feature-test, read the first fragment deliberately, and document unsupported fragmentation. Verify: The code accesses the first reported box fragment rather than treating the sequence as a scalar. 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 chart: model, boundary and recovery
Create a small science chart using a canvas redrawn at device-pixel dimensions. Combine “Display and connectivity affect observation” 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: elements with no generated box, disconnected elements or display changes have size and lifecycle consequences that should be tested. Apply: Exercise show, hide, detach and reattach cases in a disposable fixture. Verify: The resulting layout change can alter or eliminate the reported box, so state should not rely on a stale measurement. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
5. revision dashboard: model, boundary and recovery
Create a small revision dashboard using tiles responding to their container rather than viewport. Combine “Use hysteresis near thresholds” 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 component can oscillate when one layout state changes width across the same threshold that selected it. Apply: Use separated enter and exit thresholds or redesign so the class does not alter the measured decision dimension. Verify: The twenty-pixel band prevents rapid back-and-forth state changes near the boundary. 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 an expandable panel with content-driven height. Combine “disconnect releases every 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: disconnect removes all observation targets from that ResizeObserver. Apply: Call disconnect when the owning component system is destroyed. Verify: The observer no longer watches any of its former targets. 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. accessibility review: model, boundary and recovery
Create a small accessibility review using layout changes that preserve reading and focus order. Combine “Accessibility survives when semantics stay stable” 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: visual rearrangement should not create a misleading DOM, focus or announcement order, and size callbacks should not steal focus. Apply: Keep semantic source order stable and test keyboard and zoom behaviour. Verify: A layout state can change presentation without replacing the user’s active element. Then add a second chapter whose boundary could change the outcome. A complete solution contains the input model, a trace, observed evidence, a correction and one transfer statement. The exact data may differ; the causal chain must be checkable.
8. browser fixture: model, boundary and recovery
Create a small browser fixture using observed entries, cleanup and loop-error evidence. Combine “Observation is not polling” 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: the browser participates in detecting and delivering size observations, so application code need not sample dimensions on a timer. Apply: Observe the precise owner element and remove the polling loop. Verify: The callback is scheduled by the observation processing model when reportable size changes exist. 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.
