When a learner can produce a familiar result but cannot explain why a small change breaks it, the difficulty is usually not effort. The missing piece is a dependable model that connects each visible action to the state underneath.

Event delegation places one listener on a stable ancestor and interprets events that travel from descendant controls. The skill is not merely writing addEventListener once; it is proving which element initiated the event, which ancestor owns the listener, and which matching control is authorised to act. This guide teaches that model immediately, then turns it into traces, worked cases, diagnostics and independent practice.

The goal is not a catalogue of tricks. By the end, a learner should be able to predict behaviour, identify the earliest incorrect assumption, select a safe procedure, and transfer the idea to a project that does not resemble the first example.

Families in Punggol can use the chapters in short sessions around schoolwork, CCAs and rest. Ten focused minutes of prediction and explanation often reveal more than an hour of copying. The examples are proposed home-learning activities, not claims about a physical branch, class schedule, result or service.

Use disposable examples, back up important work and check current behaviour against the official documentation. Technology changes; the habit of stating a model, testing a boundary and explaining evidence remains useful.

A delegated listener observes an event at an ancestor and resolves the intended descendant action. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is imagining the event jumps directly from button to container. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Draw target, ancestors and listener location before writing the handler.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

list.addEventListener('click', onListClick);

Five deliberate variations

Variation 1: homework tracker. First, predict without running anything. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—a delegated listener observes an event at an ancestor and resolves the intended descendant action. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: library search. Next, isolate one variable and hold the others constant. Model book records with title, topic, shelf code and availability. Apply the chapter rule—a delegated listener observes an event at an ancestor and resolves the intended descendant action. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: CCA sign-up. Now, test a boundary that a comfortable example would hide. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—a delegated listener observes an event at an ancestor and resolves the intended descendant action. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: revision planner. Then, explain the result to a study partner without using jargon as a substitute for cause. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—a delegated listener observes an event at an ancestor and resolves the intended descendant action. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: canteen budget. Finally, transfer the rule to a new setting and state what would invalidate it. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—a delegated listener observes an event at an ancestor and resolves the intended descendant action. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers imagining the event jumps directly from button to container.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny reading log example using pages, dates, unfamiliar words and a one-sentence reflection. Make one ordinary case, one boundary case and one case that exposes imagining the event jumps directly from button to container. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

During propagation, an event can travel through capture, target and bubble phases according to its type and options. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is using the word bubbling for every phase. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Log eventPhase and composedPath in a tiny nested example.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

outer.addEventListener('click', log, true); outer.addEventListener('click', log);

Five deliberate variations

Variation 1: revision planner. First, predict without running anything. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—during propagation, an event can travel through capture, target and bubble phases according to its type and options. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: canteen budget. Next, isolate one variable and hold the others constant. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—during propagation, an event can travel through capture, target and bubble phases according to its type and options. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: weather journal. Now, test a boundary that a comfortable example would hide. Model daily observations with temperature, rain and a written note. Apply the chapter rule—during propagation, an event can travel through capture, target and bubble phases according to its type and options. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: reading log. Then, explain the result to a study partner without using jargon as a substitute for cause. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—during propagation, an event can travel through capture, target and bubble phases according to its type and options. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: project board. Finally, transfer the rule to a new setting and state what would invalidate it. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—during propagation, an event can travel through capture, target and bubble phases according to its type and options. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers using the word bubbling for every phase.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny project board example using tasks moving among planned, doing, review and done states. Make one ordinary case, one boundary case and one case that exposes using the word bubbling for every phase. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is reading currentTarget when the code needs the clicked control. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. State both elements aloud for clicks on the button and on a nested icon.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

menu.addEventListener('click', e => console.log(e.target, e.currentTarget));

Five deliberate variations

Variation 1: reading log. First, predict without running anything. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: project board. Next, isolate one variable and hold the others constant. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: homework tracker. Now, test a boundary that a comfortable example would hide. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: library search. Then, explain the result to a study partner without using jargon as a substitute for cause. Model book records with title, topic, shelf code and availability. Apply the chapter rule—target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: CCA sign-up. Finally, transfer the rule to a new setting and state what would invalidate it. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—target identifies where dispatch began; currentTarget identifies the node whose listener is currently running. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers reading currentTarget when the code needs the clicked control.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny homework tracker example using a short list of assignments with subject, due date and completion state. Make one ordinary case, one boundary case and one case that exposes reading currentTarget when the code needs the clicked control. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is testing only target.matches and missing clicks on child content. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Resolve with closest, then validate the result belongs to the delegated region.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

const button=e.target.closest('button[data-action]');

Five deliberate variations

Variation 1: library search. First, predict without running anything. Model book records with title, topic, shelf code and availability. Apply the chapter rule—closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: CCA sign-up. Next, isolate one variable and hold the others constant. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: revision planner. Now, test a boundary that a comfortable example would hide. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: canteen budget. Then, explain the result to a study partner without using jargon as a substitute for cause. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: weather journal. Finally, transfer the rule to a new setting and state what would invalidate it. Model daily observations with temperature, rain and a written note. Apply the chapter rule—closest(selector) climbs from the target to the nearest matching ancestor, which handles nested spans or SVG content inside a control. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers testing only target.matches and missing clicks on child content.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny library search example using book records with title, topic, shelf code and availability. Make one ordinary case, one boundary case and one case that exposes testing only target.matches and missing clicks on child content. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

A closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is trusting any selector match returned from the target chain. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Return unless control exists and container.contains(control).

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

if (!button || !menu.contains(button)) return;

Five deliberate variations

Variation 1: canteen budget. First, predict without running anything. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—a closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: weather journal. Next, isolate one variable and hold the others constant. Model daily observations with temperature, rain and a written note. Apply the chapter rule—a closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: reading log. Now, test a boundary that a comfortable example would hide. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—a closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: project board. Then, explain the result to a study partner without using jargon as a substitute for cause. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—a closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: homework tracker. Finally, transfer the rule to a new setting and state what would invalidate it. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—a closest match can sit outside the intended container when the listener or DOM relationship is unusual; containment makes ownership explicit. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers trusting any selector match returned from the target chain.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny CCA sign-up example using activity rows with a name, weekday, capacity and registered pupils. Make one ordinary case, one boundary case and one case that exposes trusting any selector match returned from the target chain. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is executing arbitrary method names taken from untrusted markup. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Map known action strings to known functions and reject everything else.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

const actions={archive,restore}; actions[button.dataset.action]?.();

Five deliberate variations

Variation 1: project board. First, predict without running anything. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: homework tracker. Next, isolate one variable and hold the others constant. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: library search. Now, test a boundary that a comfortable example would hide. Model book records with title, topic, shelf code and availability. Apply the chapter rule—data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: CCA sign-up. Then, explain the result to a study partner without using jargon as a substitute for cause. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: revision planner. Finally, transfer the rule to a new setting and state what would invalidate it. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—data-* attributes can describe a small, explicit action vocabulary without encoding behaviour in class names. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers executing arbitrary method names taken from untrusted markup.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny revision planner example using topics tagged by confidence, next review date and evidence. Make one ordinary case, one boundary case and one case that exposes executing arbitrary method names taken from untrusted markup. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is adding another listener whenever a row is rendered. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Attach once to the stable owner and test a newly inserted control.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

list.insertAdjacentHTML('beforeend','<button data-action="open">Open</button>');

Five deliberate variations

Variation 1: CCA sign-up. First, predict without running anything. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: revision planner. Next, isolate one variable and hold the others constant. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: canteen budget. Now, test a boundary that a comfortable example would hide. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: weather journal. Then, explain the result to a study partner without using jargon as a substitute for cause. Model daily observations with temperature, rain and a written note. Apply the chapter rule—delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: reading log. Finally, transfer the rule to a new setting and state what would invalidate it. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—delegation naturally covers descendants inserted after listener registration because the ancestor remains the observation point. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers adding another listener whenever a row is rendered.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny canteen budget example using items with prices, quantities and a fixed spending limit. Make one ordinary case, one boundary case and one case that exposes adding another listener whenever a row is rendered. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

The best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is delegating everything to document by default. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Choose the smallest persistent boundary and document its action vocabulary.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

panel.addEventListener('click', handlePanel);

Five deliberate variations

Variation 1: weather journal. First, predict without running anything. Model daily observations with temperature, rain and a written note. Apply the chapter rule—the best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: reading log. Next, isolate one variable and hold the others constant. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—the best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: project board. Now, test a boundary that a comfortable example would hide. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—the best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: homework tracker. Then, explain the result to a study partner without using jargon as a substitute for cause. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—the best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: library search. Finally, transfer the rule to a new setting and state what would invalidate it. Model book records with title, topic, shelf code and availability. Apply the chapter rule—the best delegate is the nearest stable owner that contains all relevant controls and no unrelated interaction region. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers delegating everything to document by default.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny weather journal example using daily observations with temperature, rain and a written note. Make one ordinary case, one boundary case and one case that exposes delegating everything to document by default. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is assuming every familiar event reaches the ancestor. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Check official event documentation and test bubbles before designing the delegate.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

form.addEventListener('focusin', highlightField);

Five deliberate variations

Variation 1: homework tracker. First, predict without running anything. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: library search. Next, isolate one variable and hold the others constant. Model book records with title, topic, shelf code and availability. Apply the chapter rule—some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: CCA sign-up. Now, test a boundary that a comfortable example would hide. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: revision planner. Then, explain the result to a study partner without using jargon as a substitute for cause. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: canteen budget. Finally, transfer the rule to a new setting and state what would invalidate it. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—some events do not bubble or have bubbling alternatives, such as focusin for focus and mouseover for mouseenter-like observation with filtering. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers assuming every familiar event reaches the ancestor.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny reading log example using pages, dates, unfamiliar words and a one-sentence reflection. Make one ordinary case, one boundary case and one case that exposes assuming every familiar event reaches the ancestor. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is delegating clicks to non-interactive div elements. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Prefer buttons and links, then add keyboard handling only when a custom pattern truly requires it.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

<button type="button" data-action="save">Save</button>

Five deliberate variations

Variation 1: revision planner. First, predict without running anything. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: canteen budget. Next, isolate one variable and hold the others constant. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: weather journal. Now, test a boundary that a comfortable example would hide. Model daily observations with temperature, rain and a written note. Apply the chapter rule—interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: reading log. Then, explain the result to a study partner without using jargon as a substitute for cause. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: project board. Finally, transfer the rule to a new setting and state what would invalidate it. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—interactive behaviour must remain available to keyboard users; native buttons already supply valuable semantics. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers delegating clicks to non-interactive div elements.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny project board example using tasks moving among planned, doing, review and done states. Make one ordinary case, one boundary case and one case that exposes delegating clicks to non-interactive div elements. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is calling preventDefault as a ritual in every handler. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Name the default action, explain the replacement and test failure behaviour.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

link.addEventListener('click', e => { if (canRoute()) { e.preventDefault(); route(); } });

Five deliberate variations

Variation 1: reading log. First, predict without running anything. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: project board. Next, isolate one variable and hold the others constant. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: homework tracker. Now, test a boundary that a comfortable example would hide. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: library search. Then, explain the result to a study partner without using jargon as a substitute for cause. Model book records with title, topic, shelf code and availability. Apply the chapter rule—preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: CCA sign-up. Finally, transfer the rule to a new setting and state what would invalidate it. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—preventDefault cancels a browser default when the application intentionally replaces it; it does not stop propagation. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers calling preventDefault as a ritual in every handler.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny homework tracker example using a short list of assignments with subject, due date and completion state. Make one ordinary case, one boundary case and one case that exposes calling preventDefault as a ritual in every handler. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is using stopPropagation to patch selector mistakes. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Fix ownership and matching first; stop only when the component contract requires isolation.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

e.stopPropagation();

Five deliberate variations

Variation 1: library search. First, predict without running anything. Model book records with title, topic, shelf code and availability. Apply the chapter rule—stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: CCA sign-up. Next, isolate one variable and hold the others constant. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: revision planner. Now, test a boundary that a comfortable example would hide. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: canteen budget. Then, explain the result to a study partner without using jargon as a substitute for cause. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: weather journal. Finally, transfer the rule to a new setting and state what would invalidate it. Model daily observations with temperature, rain and a written note. Apply the chapter rule—stopping propagation can protect a boundary but also hide events from analytics, accessibility helpers or parent components. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers using stopPropagation to patch selector mistakes.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny library search example using book records with title, topic, shelf code and availability. Make one ordinary case, one boundary case and one case that exposes using stopPropagation to patch selector mistakes. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is letting a page-level listener steal a nested widget action. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Use component-root guards and clear action namespaces.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

const card=control.closest('[data-card]'); if(!card) return;

Five deliberate variations

Variation 1: canteen budget. First, predict without running anything. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: weather journal. Next, isolate one variable and hold the others constant. Model daily observations with temperature, rain and a written note. Apply the chapter rule—nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: reading log. Now, test a boundary that a comfortable example would hide. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: project board. Then, explain the result to a study partner without using jargon as a substitute for cause. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: homework tracker. Finally, transfer the rule to a new setting and state what would invalidate it. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—nested components may both delegate, so each must recognise only its own controls and avoid interpreting a child component command. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers letting a page-level listener steal a nested widget action.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny CCA sign-up example using activity rows with a name, weekday, capacity and registered pupils. Make one ordinary case, one boundary case and one case that exposes letting a page-level listener steal a nested widget action. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Shadow boundaries retarget events; composedPath exposes the propagation path for composed events. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is expecting ordinary closest calls to cross every shadow boundary. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Treat each component boundary deliberately and inspect composedPath during debugging.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

const path=e.composedPath();

Five deliberate variations

Variation 1: project board. First, predict without running anything. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—shadow boundaries retarget events; composedPath exposes the propagation path for composed events. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: homework tracker. Next, isolate one variable and hold the others constant. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—shadow boundaries retarget events; composedPath exposes the propagation path for composed events. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: library search. Now, test a boundary that a comfortable example would hide. Model book records with title, topic, shelf code and availability. Apply the chapter rule—shadow boundaries retarget events; composedPath exposes the propagation path for composed events. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: CCA sign-up. Then, explain the result to a study partner without using jargon as a substitute for cause. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—shadow boundaries retarget events; composedPath exposes the propagation path for composed events. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: revision planner. Finally, transfer the rule to a new setting and state what would invalidate it. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—shadow boundaries retarget events; composedPath exposes the propagation path for composed events. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers expecting ordinary closest calls to cross every shadow boundary.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny revision planner example using topics tagged by confidence, next review date and evidence. Make one ordinary case, one boundary case and one case that exposes expecting ordinary closest calls to cross every shadow boundary. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is copying passive:true while still needing preventDefault. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Select each option from a stated requirement and use AbortSignal for grouped cleanup.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

root.addEventListener('click', handler, {signal: controller.signal});

Five deliberate variations

Variation 1: CCA sign-up. First, predict without running anything. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: revision planner. Next, isolate one variable and hold the others constant. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: canteen budget. Now, test a boundary that a comfortable example would hide. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: weather journal. Then, explain the result to a study partner without using jargon as a substitute for cause. Model daily observations with temperature, rain and a written note. Apply the chapter rule—capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: reading log. Finally, transfer the rule to a new setting and state what would invalidate it. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—capture, once, passive and signal change listener timing, repetition, cancellation and cleanup. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers copying passive:true while still needing preventDefault.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny canteen budget example using items with prices, quantities and a fixed spending limit. Make one ordinary case, one boundary case and one case that exposes copying passive:true while still needing preventDefault. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Delegation can reduce listener count, but selector work and broad handlers still cost time. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is claiming one listener is always faster without measurement. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Measure realistic interaction, keep selectors narrow and prefer clarity for small static sets.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

performance.mark('delegate-start');

Five deliberate variations

Variation 1: weather journal. First, predict without running anything. Model daily observations with temperature, rain and a written note. Apply the chapter rule—delegation can reduce listener count, but selector work and broad handlers still cost time. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: reading log. Next, isolate one variable and hold the others constant. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—delegation can reduce listener count, but selector work and broad handlers still cost time. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: project board. Now, test a boundary that a comfortable example would hide. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—delegation can reduce listener count, but selector work and broad handlers still cost time. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: homework tracker. Then, explain the result to a study partner without using jargon as a substitute for cause. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—delegation can reduce listener count, but selector work and broad handlers still cost time. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: library search. Finally, transfer the rule to a new setting and state what would invalidate it. Model book records with title, topic, shelf code and availability. Apply the chapter rule—delegation can reduce listener count, but selector work and broad handlers still cost time. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers claiming one listener is always faster without measurement.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny weather journal example using daily observations with temperature, rain and a written note. Make one ordinary case, one boundary case and one case that exposes claiming one listener is always faster without measurement. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Delegated actions must preserve names, roles, focus order and visible status updates. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is changing the interface without announcing or focusing the result. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Test keyboard-only use and appropriate live-region or focus behaviour.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

status.textContent='Saved';

Five deliberate variations

Variation 1: homework tracker. First, predict without running anything. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—delegated actions must preserve names, roles, focus order and visible status updates. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: library search. Next, isolate one variable and hold the others constant. Model book records with title, topic, shelf code and availability. Apply the chapter rule—delegated actions must preserve names, roles, focus order and visible status updates. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: CCA sign-up. Now, test a boundary that a comfortable example would hide. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—delegated actions must preserve names, roles, focus order and visible status updates. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: revision planner. Then, explain the result to a study partner without using jargon as a substitute for cause. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—delegated actions must preserve names, roles, focus order and visible status updates. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: canteen budget. Finally, transfer the rule to a new setting and state what would invalidate it. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—delegated actions must preserve names, roles, focus order and visible status updates. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers changing the interface without announcing or focusing the result.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny reading log example using pages, dates, unfamiliar words and a one-sentence reflection. Make one ordinary case, one boundary case and one case that exposes changing the interface without announcing or focusing the result. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

A useful test dispatches from nested content, asserts the resolved control and checks ignored targets. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is testing only a direct click on the button element. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Include dynamic insertion, nested icons, unrelated controls and cleanup.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

icon.dispatchEvent(new MouseEvent('click',{bubbles:true}));

Five deliberate variations

Variation 1: revision planner. First, predict without running anything. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—a useful test dispatches from nested content, asserts the resolved control and checks ignored targets. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: canteen budget. Next, isolate one variable and hold the others constant. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—a useful test dispatches from nested content, asserts the resolved control and checks ignored targets. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: weather journal. Now, test a boundary that a comfortable example would hide. Model daily observations with temperature, rain and a written note. Apply the chapter rule—a useful test dispatches from nested content, asserts the resolved control and checks ignored targets. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: reading log. Then, explain the result to a study partner without using jargon as a substitute for cause. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—a useful test dispatches from nested content, asserts the resolved control and checks ignored targets. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: project board. Finally, transfer the rule to a new setting and state what would invalidate it. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—a useful test dispatches from nested content, asserts the resolved control and checks ignored targets. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers testing only a direct click on the button element.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny project board example using tasks moving among planned, doing, review and done states. Make one ordinary case, one boundary case and one case that exposes testing only a direct click on the button element. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is adding broader selectors until the click appears to work. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Log one event record and identify the first incorrect assumption.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

console.table({target:e.target,currentTarget:e.currentTarget});

Five deliberate variations

Variation 1: reading log. First, predict without running anything. Model pages, dates, unfamiliar words and a one-sentence reflection. Apply the chapter rule—debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: project board. Next, isolate one variable and hold the others constant. Model tasks moving among planned, doing, review and done states. Apply the chapter rule—debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: homework tracker. Now, test a boundary that a comfortable example would hide. Model a short list of assignments with subject, due date and completion state. Apply the chapter rule—debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: library search. Then, explain the result to a study partner without using jargon as a substitute for cause. Model book records with title, topic, shelf code and availability. Apply the chapter rule—debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: CCA sign-up. Finally, transfer the rule to a new setting and state what would invalidate it. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—debugging begins with target, currentTarget, path, resolved control and containment—not with random selector changes. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers adding broader selectors until the click appears to work.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny homework tracker example using a short list of assignments with subject, due date and completion state. Make one ordinary case, one boundary case and one case that exposes adding broader selectors until the click appears to work. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. This is the chapter’s governing idea. A learner should be able to restate it in ordinary language, point to the relevant state in an example, and predict the consequence of one controlled change. Those three actions distinguish a working mental model from a phrase copied from a reference page.

The common trap is using delegation merely because the pattern is fashionable. That error is informative: it shows which boundary the learner has not yet represented. Correct the earliest wrong assumption, not merely the final line. Compare delegated and direct listeners for the same widget and defend the simpler contract.

For a short Punggol home session, use a prediction–observation–explanation cycle. Write the prediction before using the interpreter, browser or terminal. Record the observation exactly. Then write one causal sentence containing “because”. If the sentence only repeats the output, shrink the case until every transition can be named.

Core worked example

toolbar.addEventListener('click', handleToolbar);

Five deliberate variations

Variation 1: library search. First, predict without running anything. Model book records with title, topic, shelf code and availability. Apply the chapter rule—mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 2: CCA sign-up. Next, isolate one variable and hold the others constant. Model activity rows with a name, weekday, capacity and registered pupils. Apply the chapter rule—mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 3: revision planner. Now, test a boundary that a comfortable example would hide. Model topics tagged by confidence, next review date and evidence. Apply the chapter rule—mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 4: canteen budget. Then, explain the result to a study partner without using jargon as a substitute for cause. Model items with prices, quantities and a fixed spending limit. Apply the chapter rule—mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Variation 5: weather journal. Finally, transfer the rule to a new setting and state what would invalidate it. Model daily observations with temperature, rain and a written note. Apply the chapter rule—mastery means choosing delegation because ownership, propagation and lifecycle form a coherent component contract. Before using a tool, state what remains unchanged, what is being varied, and which visible result would disprove the prediction.

Diagnostic route

• If the vocabulary is unclear: ask the learner to point to the concrete element represented by each noun in the rule.
• If the prediction is wrong: find the first state where the written trace differs from the observed trace.
• If the output is right but the explanation is weak: introduce one near-miss that triggers using delegation merely because the pattern is fashionable.
• If the example is easy: transfer it to a second context and require the learner to name the invariant.
• If the tool behaves differently: consult the linked official documentation and record the relevant version or environment.

A parent does not need to supply the technical answer. Ask: “What did you expect?”, “What evidence changed your mind?”, and “What is the smallest example that keeps the problem?” Those questions protect learner ownership while still making an evening practice session structured and calm.

Practice with an explained answer

Question. Design a tiny library search example using book records with title, topic, shelf code and availability. Make one ordinary case, one boundary case and one case that exposes using delegation merely because the pattern is fashionable. Predict all three, run or inspect them, and state whether the governing idea needs qualification.

Transfer and decision point

Transfer this chapter to an unfamiliar project by separating mechanism from policy. The mechanism is what the language, browser or Git command does. The policy is what this project intends to preserve. When those are blended, a technically valid operation can still be educationally or operationally wrong. Write both statements, choose a reversible test, and keep important work backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not labels such as careless or weak. Ask the learner to predict one small case, then compare the prediction with the observed trace. A mismatch at the first step suggests the mental model needs rebuilding. A correct model with syntax errors calls for focused reference use. Correct routine cases but weak boundary cases call for deliberate variation. Correct explanations across new contexts indicate readiness for a project.

A useful weekly record has four short fields: concept attempted, prediction, observed difference and next test. It should not become a surveillance log. Its purpose is to make progress visible and help the learner choose the next task. Stop a session when fatigue replaces reasoning; return with a smaller case rather than adding pressure.

Seek specialised help when a learner repeatedly cannot connect cause and effect despite smaller examples, when accessibility or safety implications are unclear, or when important repository or project data may be at risk. The right help should make thinking more visible and independent, not create dependence on a hidden answer.

1. homework tracker: plan, predict and verify

Build a small homework tracker using a short list of assignments with subject, due date and completion state. Apply “The delegation mental model” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

2. library search: plan, predict and verify

Build a small library search using book records with title, topic, shelf code and availability. Apply “Resolving controls with closest” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

3. CCA sign-up: plan, predict and verify

Build a small CCA sign-up using activity rows with a name, weekday, capacity and registered pupils. Apply “Dynamic descendants” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

4. revision planner: plan, predict and verify

Build a small revision planner using topics tagged by confidence, next review date and evidence. Apply “Keyboard and click parity” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

5. canteen budget: plan, predict and verify

Build a small canteen budget using items with prices, quantities and a fixed spending limit. Apply “Nested delegates” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

6. weather journal: plan, predict and verify

Build a small weather journal using daily observations with temperature, rain and a written note. Apply “Performance without mythology” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

7. reading log: plan, predict and verify

Build a small reading log using pages, dates, unfamiliar words and a one-sentence reflection. Apply “Debugging false matches” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

8. project board: plan, predict and verify

Build a small project board using tasks moving among planned, doing, review and done states. Apply “Propagation and the event path” and one later chapter of your choice. Include an ordinary case, a boundary, a deliberate failure and a recovery. Before using a tool, write the expected state after each important step.

Frequently asked questions

How long should one practice session be?

Long enough to complete one prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be productive; stop before the work becomes mechanical.

Should a learner memorise every rule first?

No. Keep a small set of governing ideas available, then practise retrieving and applying them. Reference use is part of real technical work, but the learner must still explain the result.

What if the example works but the learner cannot explain it?

Treat that as an incomplete success. Ask for a trace, change one boundary and compare. Reliable understanding survives a controlled variation.

Is the shortest solution the best solution?

Not automatically. Prefer the solution whose policy, failure modes and maintenance cost are easiest to justify for the actual reader and project.

When should official documentation be used?

Use it when syntax, event behaviour, CSS triggers, Git options or version details matter. Tutorials can orient; the primary reference settles the contract.

How can a parent help without knowing the subject?

Ask evidence questions: What did you predict? Which step differed? What is the smallest reproduction? What will you test next?

How do we know the skill transfers?

Give a new context with different names and one unfamiliar boundary. Ask the learner to identify the invariant before writing code or running a command.

What should be saved from the lesson?

Save a brief trace, the corrected rule, one boundary example and a next-step question. Avoid keeping pages of copied output with no explanation.

Can this guide replace project backups?

No. Use disposable examples and proper backups. Learning exercises should not place important schoolwork, repositories or personal data at risk.

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 official reference.

Official and supporting references

• Primary technical documentation for JavaScript event delegation
• eduKatePunggol: How Studying Works

Return to contents