When a learner can reproduce a familiar example but a small variation causes confusion, the problem is usually an incomplete model rather than a lack of effort. The fastest useful response is to expose the hidden state and test one boundary at a time.

CSS Anchor Positioning lets an absolutely or fixed positioned box use another box as a geometric reference without copying coordinates into JavaScript. Mastery means naming and selecting the correct anchor, distinguishing anchor() offsets from position-area regions, sizing with anchor-size(), designing overflow fallbacks with position-try, scoping repeated component names, checking visibility and scroll behaviour, preserving DOM order and keyboard access, and treating the evolving specification as progressive enhancement with a complete non-anchor fallback. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

The aim is independent reasoning. A learner should be able to predict behaviour, locate the earliest wrong assumption, use a safe diagnostic procedure and defend a design choice in a new project.

Punggol families can use the guide in short sessions around homework, CCAs and rest. The activities are proposed learning exercises, not claims about a physical branch, timetable, class size, fee, school relationship or guaranteed result.

Use disposable data and repositories, preserve backups, and check version-sensitive details against the official source. Current documentation settles a technical contract; observation and explanation turn that contract into usable knowledge.

anchor-name assigns one or more dashed identifiers that eligible positioned descendants or later elements can reference. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using a class name without declaring an anchor name. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect computed anchor-name and keep the custom identifier specific to the component.

For the anchor-name exposes a reference box chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a class name without declaring an anchor name. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.trigger{anchor-name:--study-trigger}

Four purposeful transfer cases

Case 1: homework tooltip. Predict the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library menu. Contrast the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Stress-test the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science annotation. Explain the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using a class name without declaring an anchor name.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect computed anchor-name and keep the custom identifier specific to the component.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from anchor-name exposes a reference box?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a class name without declaring an anchor name be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with a date menu avoids viewport overflow with fallbacks. Include one ordinary case, one boundary and one deliberate failure caused by using a class name without declaring an anchor name. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For anchor-name exposes a reference box, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-anchor assigns the positioned box’s default anchor name, allowing anchor functions and position-area to omit a repeated name. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is declaring anchor-name on the popup instead of the trigger. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name the source box and set position-anchor on the absolutely or fixed positioned target.

For the position-anchor selects the default anchor chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on declaring anchor-name on the popup instead of the trigger. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{position:absolute;position-anchor:--study-trigger}

Four purposeful transfer cases

Case 1: CCA badge. Contrast the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science annotation. Stress-test the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Explain the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Transfer the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers declaring anchor-name on the popup instead of the trigger.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Name the source box and set position-anchor on the absolutely or fixed positioned target.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from position-anchor selects the default anchor?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing declaring anchor-name on the popup instead of the trigger be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny accessibility fixture with DOM order, focus and reduced motion remain independent of geometry. Include one ordinary case, one boundary and one deliberate failure caused by declaring anchor-name on the popup instead of the trigger. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For position-anchor selects the default anchor, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor positioning features apply through absolute or fixed positioning rules and do not turn a normal-flow box into an anchored overlay automatically. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding anchor() to a static element and expecting it to leave normal flow. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Verify position, containing block and default anchor before tuning offsets.

For the The positioned target needs the right positioning scheme chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding anchor() to a static element and expecting it to leave normal flow. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{position:fixed;position-anchor:--study-trigger}

Four purposeful transfer cases

Case 1: revision card. Stress-test the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Explain the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: accessibility fixture. Transfer the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: support matrix. Predict the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding anchor() to a static element and expecting it to leave normal flow.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Verify position, containing block and default anchor before tuning offsets.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from The positioned target needs the right positioning scheme?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding anchor() to a static element and expecting it to leave normal flow be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny support matrix with anchor support and ordinary positioned fallback are compared. Include one ordinary case, one boundary and one deliberate failure caused by adding anchor() to a static element and expecting it to leave normal flow. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The positioned target needs the right positioning scheme, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor() resolves an inset from a side of the anchor box, with physical, logical or percentage forms defined by the current specification. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using anchor(top) on the wrong inset axis without drawing the geometry. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Draw target inset, anchor side and containing block on one diagram before writing the value.

For the anchor reads a chosen anchor edge chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using anchor(top) on the wrong inset axis without drawing the geometry. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{top:anchor(bottom);left:anchor(left)}

Four purposeful transfer cases

Case 1: accessibility fixture. Explain the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: support matrix. Transfer the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework tooltip. Predict the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library menu. Contrast the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using anchor(top) on the wrong inset axis without drawing the geometry.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Draw target inset, anchor side and containing block on one diagram before writing the value.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from anchor reads a chosen anchor edge?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using anchor(top) on the wrong inset axis without drawing the geometry be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework tooltip with a short explanation follows the selected question button. Include one ordinary case, one boundary and one deliberate failure caused by using anchor(top) on the wrong inset axis without drawing the geometry. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For anchor reads a chosen anchor edge, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor() can name a particular anchor, while an omitted name uses the target’s default anchor where one exists. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is mixing two anchor names in one rule without stating which measurement belongs to which source. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write explicit names during diagnosis, then omit only when the default is unambiguous.

For the An explicit name can override the default chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mixing two anchor names in one rule without stating which measurement belongs to which source. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{top:anchor(--study-trigger bottom)}

Four purposeful transfer cases

Case 1: homework tooltip. Transfer the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library menu. Predict the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Contrast the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science annotation. Stress-test the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers mixing two anchor names in one rule without stating which measurement belongs to which source.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Write explicit names during diagnosis, then omit only when the default is unambiguous.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from An explicit name can override the default?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mixing two anchor names in one rule without stating which measurement belongs to which source be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library menu with a catalogue popover chooses space above or below its trigger. Include one ordinary case, one boundary and one deliberate failure caused by mixing two anchor names in one rule without stating which measurement belongs to which source. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For An explicit name can override the default, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor() accepts a fallback length or percentage for cases where the anchor query cannot resolve validly. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming an invalid anchor measurement always becomes a useful auto position. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Supply a deliberate fallback and test the missing-anchor branch.

For the Fallback values protect unavailable measurements chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming an invalid anchor measurement always becomes a useful auto position. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{top:anchor(--study-trigger bottom,1rem)}

Four purposeful transfer cases

Case 1: CCA badge. Predict the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science annotation. Contrast the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Stress-test the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Explain the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming an invalid anchor measurement always becomes a useful auto position.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Supply a deliberate fallback and test the missing-anchor branch.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Fallback values protect unavailable measurements?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming an invalid anchor measurement always becomes a useful auto position be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA badge with a status label remains attached across writing modes. Include one ordinary case, one boundary and one deliberate failure caused by assuming an invalid anchor measurement always becomes a useful auto position. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Fallback values protect unavailable measurements, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor-size() lets sizing and supported calculations refer to width, height or logical dimensions of an anchor box. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is copying trigger width into JavaScript on every resize. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use anchor-size with a minimum or maximum policy and test narrow and wide triggers.

For the anchor-size reads anchor dimensions chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on copying trigger width into JavaScript on every resize. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{min-width:anchor-size(width)}

Four purposeful transfer cases

Case 1: revision card. Contrast the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Stress-test the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: accessibility fixture. Explain the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: support matrix. Transfer the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers copying trigger width into JavaScript on every resize.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use anchor-size with a minimum or maximum policy and test narrow and wide triggers.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from anchor-size reads anchor dimensions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing copying trigger width into JavaScript on every resize be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science annotation with a callout uses an image marker as its anchor. Include one ordinary case, one boundary and one deliberate failure caused by copying trigger width into JavaScript on every resize. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For anchor-size reads anchor dimensions, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-area selects a region from the 3 by 3 grid formed by the containing block and default anchor edges. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating position-area as another transform coordinate. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose the semantic region first, then use alignment and margins for fine spacing.

For the position-area chooses a region around the anchor chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating position-area as another transform coordinate. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{position-area:block-end span-inline-end}

Four purposeful transfer cases

Case 1: accessibility fixture. Stress-test the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: support matrix. Explain the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework tooltip. Transfer the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library menu. Predict the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating position-area as another transform coordinate.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Choose the semantic region first, then use alignment and margins for fine spacing.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from position-area chooses a region around the anchor?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating position-area as another transform coordinate be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision card with repeated cards scope the same local anchor name safely. Include one ordinary case, one boundary and one deliberate failure caused by treating position-area as another transform coordinate. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For position-area chooses a region around the anchor, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

flow-relative position-area values such as block-start and inline-end follow writing mode and direction rather than hard-coded screen edges. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using top right for a component expected to support RTL or vertical text. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test ltr, rtl and a vertical writing mode with the same logical declaration.

For the Logical areas survive writing-mode changes chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using top right for a component expected to support RTL or vertical text. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.badge{position-area:block-start inline-end}

Four purposeful transfer cases

Case 1: homework tooltip. Explain the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library menu. Transfer the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Predict the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science annotation. Contrast the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using top right for a component expected to support RTL or vertical text.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test ltr, rtl and a vertical writing mode with the same logical declaration.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Logical areas survive writing-mode changes?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using top right for a component expected to support RTL or vertical text be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with a date menu avoids viewport overflow with fallbacks. Include one ordinary case, one boundary and one deliberate failure caused by using top right for a component expected to support RTL or vertical text. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Logical areas survive writing-mode changes, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-area modifies the containing block and gives auto insets and normal self-alignment area-specific behaviour. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding compensating transforms before inspecting default alignment. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Remove transforms, inspect the chosen area and then set justify-self or align-self only if needed.

For the Alignment resolves inside the selected area chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding compensating transforms before inspecting default alignment. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{position-area:block-end;justify-self:center}

Four purposeful transfer cases

Case 1: CCA badge. Transfer the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science annotation. Predict the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Contrast the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Stress-test the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding compensating transforms before inspecting default alignment.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Remove transforms, inspect the chosen area and then set justify-self or align-self only if needed.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Alignment resolves inside the selected area?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding compensating transforms before inspecting default alignment be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny accessibility fixture with DOM order, focus and reduced motion remain independent of geometry. Include one ordinary case, one boundary and one deliberate failure caused by adding compensating transforms before inspecting default alignment. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Alignment resolves inside the selected area, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-try-fallbacks supplies alternative position options when the base placement overflows its inset-modified containing block. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using one placement and letting a menu disappear beyond the viewport. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Create a small viewport fixture and record which alternative becomes the first non-overflowing option.

For the position-try-fallbacks lists alternatives chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using one placement and letting a menu disappear beyond the viewport. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{position-area:block-end;position-try-fallbacks:flip-block}

Four purposeful transfer cases

Case 1: revision card. Predict the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Contrast the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: accessibility fixture. Stress-test the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: support matrix. Explain the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using one placement and letting a menu disappear beyond the viewport.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Create a small viewport fixture and record which alternative becomes the first non-overflowing option.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from position-try-fallbacks lists alternatives?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using one placement and letting a menu disappear beyond the viewport be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny support matrix with anchor support and ordinary positioned fallback are compared. Include one ordinary case, one boundary and one deliberate failure caused by using one placement and letting a menu disappear beyond the viewport. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For position-try-fallbacks lists alternatives, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

flip-block, flip-inline and related try tactics derive common mirrored alternatives without a custom rule. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is writing duplicate top, bottom, left and right rules that drift apart. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Start with one base option and add only the axes that need flipping.

For the Built-in flip tactics transform the base option chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing duplicate top, bottom, left and right rules that drift apart. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{position-try-fallbacks:flip-block,flip-inline,flip-block flip-inline}

Four purposeful transfer cases

Case 1: accessibility fixture. Contrast the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: support matrix. Stress-test the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework tooltip. Explain the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library menu. Transfer the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers writing duplicate top, bottom, left and right rules that drift apart.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Start with one base option and add only the axes that need flipping.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Built-in flip tactics transform the base option?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing duplicate top, bottom, left and right rules that drift apart be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework tooltip with a short explanation follows the selected question button. Include one ordinary case, one boundary and one deliberate failure caused by writing duplicate top, bottom, left and right rules that drift apart. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Built-in flip tactics transform the base option, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

a named @position-try rule can provide accepted positioning, margin and sizing declarations for a reusable fallback. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is putting unrelated colour or typography declarations into a position option. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep the custom rule limited to the accepted placement properties and test it after the built-in options.

For the @position-try defines a named custom option chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on putting unrelated colour or typography declarations into a position option. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@position-try --compact-top{
  position-area:block-start;
  max-height:40vh;
}

Four purposeful transfer cases

Case 1: homework tooltip. Stress-test the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library menu. Explain the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Transfer the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science annotation. Predict the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers putting unrelated colour or typography declarations into a position option.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep the custom rule limited to the accepted placement properties and test it after the built-in options.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from @position-try defines a named custom option?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing putting unrelated colour or typography declarations into a position option be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library menu with a catalogue popover chooses space above or below its trigger. Include one ordinary case, one boundary and one deliberate failure caused by putting unrelated colour or typography declarations into a position option. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For @position-try defines a named custom option, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-try-order can stably reorder options according to criteria such as most height before overflow testing chooses a successful option. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming the written first option always receives first consideration after an order preference. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Log viewport dimensions and compare the chosen option above and below the trigger.

For the position-try-order can prefer available space chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the written first option always receives first consideration after an order preference. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.menu{position-try:most-height --bottom-scrollable,flip-block,--top-scrollable}

Four purposeful transfer cases

Case 1: CCA badge. Explain the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science annotation. Transfer the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Predict the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Contrast the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming the written first option always receives first consideration after an order preference.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Log viewport dimensions and compare the chosen option above and below the trigger.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from position-try-order can prefer available space?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the written first option always receives first consideration after an order preference be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA badge with a status label remains attached across writing modes. Include one ordinary case, one boundary and one deliberate failure caused by assuming the written first option always receives first consideration after an order preference. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For position-try-order can prefer available space, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

position-visibility can hide an anchored box when anchor validity, anchor visibility or overflow conditions do not satisfy the chosen policy. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is leaving a detached tooltip floating after its anchor scrolls away. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test anchor-visible, no-overflow and always deliberately with scrolling and clipping.

For the position-visibility controls conditional hiding chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on leaving a detached tooltip floating after its anchor scrolls away. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{position-visibility:anchor-visible}

Four purposeful transfer cases

Case 1: revision card. Transfer the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Predict the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: accessibility fixture. Contrast the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: support matrix. Stress-test the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers leaving a detached tooltip floating after its anchor scrolls away.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test anchor-visible, no-overflow and always deliberately with scrolling and clipping.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from position-visibility controls conditional hiding?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing leaving a detached tooltip floating after its anchor scrolls away be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science annotation with a callout uses an image marker as its anchor. Include one ordinary case, one boundary and one deliberate failure caused by leaving a detached tooltip floating after its anchor scrolls away. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For position-visibility controls conditional hiding, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor-scope limits named anchors within a subtree so repeated components can reuse one local dashed identifier safely. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is letting every repeated card resolve to the last matching anchor on the page. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Place anchor-name and anchor-scope on each component boundary and inspect several simultaneous cards.

For the anchor-scope prevents repeated-name collisions chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on letting every repeated card resolve to the last matching anchor on the page. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.card{anchor-name:--card;anchor-scope:--card}
.card .tip{position-anchor:--card}

Four purposeful transfer cases

Case 1: accessibility fixture. Predict the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: support matrix. Contrast the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework tooltip. Stress-test the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library menu. Explain the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers letting every repeated card resolve to the last matching anchor on the page.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Place anchor-name and anchor-scope on each component boundary and inspect several simultaneous cards.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from anchor-scope prevents repeated-name collisions?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing letting every repeated card resolve to the last matching anchor on the page be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision card with repeated cards scope the same local anchor name safely. Include one ordinary case, one boundary and one deliberate failure caused by letting every repeated card resolve to the last matching anchor on the page. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For anchor-scope prevents repeated-name collisions, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

anchor measurements operate within positioned layout rules, so transforms, containment, overflow and the target’s containing block can change the result. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is debugging every offset as an anchor-name failure. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Outline the containing block and overflow ancestors before changing the anchor expressions.

For the Containing blocks still govern geometry chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on debugging every offset as an anchor-name failure. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.panel{position:relative;overflow:clip}

Four purposeful transfer cases

Case 1: homework tooltip. Contrast the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library menu. Stress-test the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Explain the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science annotation. Transfer the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers debugging every offset as an anchor-name failure.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Outline the containing block and overflow ancestors before changing the anchor expressions.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Containing blocks still govern geometry?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing debugging every offset as an anchor-name failure be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family planner with a date menu avoids viewport overflow with fallbacks. Include one ordinary case, one boundary and one deliberate failure caused by debugging every offset as an anchor-name failure. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Containing blocks still govern geometry, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

an anchored overlay can move, clip or become conditionally hidden as its anchor and containing blocks scroll. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is checking only a still desktop screenshot. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Scroll each relevant ancestor, zoom, resize and test keyboard focus while the overlay is open.

For the Scroll and visibility need real interaction tests chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on checking only a still desktop screenshot. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

scroller.scrollTop=200;
// observe target and anchor rectangles

Four purposeful transfer cases

Case 1: CCA badge. Stress-test the rule using a status label remains attached across writing modes. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science annotation. Explain the rule using a callout uses an image marker as its anchor. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Transfer the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family planner. Predict the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers checking only a still desktop screenshot.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Scroll each relevant ancestor, zoom, resize and test keyboard focus while the overlay is open.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Scroll and visibility need real interaction tests?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing checking only a still desktop screenshot be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny accessibility fixture with DOM order, focus and reduced motion remain independent of geometry. Include one ordinary case, one boundary and one deliberate failure caused by checking only a still desktop screenshot. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Scroll and visibility need real interaction tests, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

visual placement near an anchor does not change document order, focus order, accessible naming or ownership of the interactive control. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is moving a popup visually and assuming assistive technology follows the same relationship. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep trigger and popup semantics explicit with native controls, labels and managed focus.

For the DOM order and focus remain semantic chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on moving a popup visually and assuming assistive technology follows the same relationship. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

button.setAttribute('aria-expanded','true');
menu.focus();

Four purposeful transfer cases

Case 1: revision card. Explain the rule using repeated cards scope the same local anchor name safely. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family planner. Transfer the rule using a date menu avoids viewport overflow with fallbacks. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: accessibility fixture. Predict the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: support matrix. Contrast the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers moving a popup visually and assuming assistive technology follows the same relationship.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep trigger and popup semantics explicit with native controls, labels and managed focus.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from DOM order and focus remain semantic?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing moving a popup visually and assuming assistive technology follows the same relationship be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny support matrix with anchor support and ordinary positioned fallback are compared. Include one ordinary case, one boundary and one deliberate failure caused by moving a popup visually and assuming assistive technology follows the same relationship. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For DOM order and focus remain semantic, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

the specification and implementations evolve, so a complete design keeps a conventional positioned fallback and applies anchor rules only when supported. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is shipping an essential control that works only when anchor-name parses. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test the fallback first, then guard the enhancement with @supports and a browser matrix.

For the Anchor positioning is progressive enhancement chapter on CSS Anchor Positioning, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on shipping an essential control that works only when anchor-name parses. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.tip{position:absolute;inset:100% auto auto 0}
@supports(anchor-name:--a){.tip{position-anchor:--a;position-area:block-end}}

Four purposeful transfer cases

Case 1: accessibility fixture. Transfer the rule using DOM order, focus and reduced motion remain independent of geometry. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: support matrix. Predict the rule using anchor support and ordinary positioned fallback are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework tooltip. Contrast the rule using a short explanation follows the selected question button. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library menu. Stress-test the rule using a catalogue popover chooses space above or below its trigger. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers shipping an essential control that works only when anchor-name parses.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test the fallback first, then guard the enhancement with @supports and a browser matrix.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS Anchor Positioning syntax. For this chapter, useful prompts are: “What did you expect from Anchor positioning is progressive enhancement?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing shipping an essential control that works only when anchor-name parses be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework tooltip with a short explanation follows the selected question button. Include one ordinary case, one boundary and one deliberate failure caused by shipping an essential control that works only when anchor-name parses. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Anchor positioning is progressive enhancement, separate the documented CSS Anchor Positioning mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Start with evidence, not a label such as careless. Ask for one prediction and one trace. If the first transition is wrong, rebuild the model. If the model is sound but syntax fails, practise reference use. If routine cases are correct but boundaries fail, vary ties, defaults, unsupported inputs, ownership or missing paths. If explanations transfer, move to a small project.

Keep a weekly record with four lines: concept, prediction, observed difference and next test. Stop when fatigue replaces reasoning. A smaller case tomorrow is more useful than another hour of copying tonight.

Seek specialist help when cause and effect remain invisible after examples are reduced, when accessibility or data-loss implications are unclear, or when an important repository, database or application state may be at risk. Good support should make the learner’s reasoning more independent.

1. homework tooltip: model, boundary and recovery

Create a small homework tooltip using a short explanation follows the selected question button. Combine “anchor-name exposes a reference box” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. library menu: model, boundary and recovery

Create a small library menu using a catalogue popover chooses space above or below its trigger. Combine “anchor reads a chosen anchor edge” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. CCA badge: model, boundary and recovery

Create a small CCA badge using a status label remains attached across writing modes. Combine “anchor-size reads anchor dimensions” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. science annotation: model, boundary and recovery

Create a small science annotation using a callout uses an image marker as its anchor. Combine “Alignment resolves inside the selected area” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. revision card: model, boundary and recovery

Create a small revision card using repeated cards scope the same local anchor name safely. Combine “@position-try defines a named custom option” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. family planner: model, boundary and recovery

Create a small family planner using a date menu avoids viewport overflow with fallbacks. Combine “anchor-scope prevents repeated-name collisions” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. accessibility fixture: model, boundary and recovery

Create a small accessibility fixture using DOM order, focus and reduced motion remain independent of geometry. Combine “DOM order and focus remain semantic” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. support matrix: model, boundary and recovery

Create a small support matrix using anchor support and ordinary positioned fallback are compared. Combine “position-anchor selects the default anchor” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

Use one complete prediction–observation–explanation cycle while attention remains good. Ten to twenty focused minutes can be enough.

Should every option or function be memorised?

No. Memorise the governing distinctions and practise retrieving the official reference. Understanding means predicting and explaining, not reciting a parameter list.

What if the result is correct but the explanation is weak?

Treat it as partial success. Ask for a trace and change one boundary. A reliable model survives controlled variation.

Is the shortest solution the best?

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

When should official documentation be used?

Use it whenever syntax, supported types, SQL dialect behaviour or Git version details matter. Primary documentation settles the current contract.

How can a parent help without technical expertise?

Ask what was predicted, where the first difference appeared, what evidence matters and which smaller example could isolate it.

How do we test transfer?

Change the context, vocabulary and one boundary. Require the learner to identify the invariant before using a tool.

What should be saved after practice?

Keep the corrected rule, one trace, one boundary case and the next question. Avoid storing pages of unexplained output.

Can these exercises replace backups?

No. Use disposable examples and proper backups. Learning should not endanger schoolwork, repositories or personal data.

What counts as mastery?

The learner can predict, verify, diagnose, recover and justify a choice across more than one context, while knowing when to consult the current reference.

Official and supporting references

• Primary technical documentation for CSS Anchor Positioning
• eduKatePunggol: How Studying Works

Return to contents