PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner is hand-numbering every card with custom properties just to create a simple progression, CSS tree-counting functions offer a cleaner mental model—but only when their draft status, DOM-tree semantics and fallback needs are understood.

The central rule is simple: sibling-index() is the one-based inclusive position of the originating element among element siblings, while sibling-count() is the total number of element children of the parent. They return integers for calculations, use DOM-tree counting rather than flat-tree visual order, and require progressive enhancement because implementation support is still developing.

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

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

The official technical reference for this article is CSS Values and Units Level 5 draft, tree-counting functions. Where the feature is version-sensitive or still developing, the article states that boundary explicitly. Examples were independently checked against the runtime or specification named in the reference section.

Choose a reading route

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

Start from the model: Chapters 1–4. Begin with What sibling-index() returns and continue in order to DOM tree counting, not the flat tree.

Diagnose a confusing result: Chapters 5–8. Begin with Only element children contribute to the count and continue in order to Reverse position from the end.

Build reliable examples: Chapters 9–12. Begin with Normalised progress across siblings and continue in order to Generated pseudo-elements and originating elements.

Transfer to real work: Chapters 13–16. Begin with Element-backed pseudo-elements can have their own tree context and continue in order to Relationship to CSS counters.

Decide and teach: Chapters 17–20. Begin with Progressive enhancement with @supports and continue in order to Choosing sibling functions for the right design.

Open the full 20-chapter index

1. 1. What sibling-index() returns
2. 2. What sibling-count() returns
3. 3. The functions return integers usable in calculations
4. 4. DOM tree counting, not the flat tree
5. 5. Only element children contribute to the count
6. 6. A staggered delay without author-numbered variables
7. 7. Size progression by index
8. 8. Reverse position from the end
9. 9. Normalised progress across siblings
10. 10. Dynamic insertion updates positions
11. 11. Removal has the inverse dependency pattern
12. 12. Generated pseudo-elements and originating elements
13. 13. Element-backed pseudo-elements can have their own tree context
14. 14. Shadow-scoped references may resolve to zero
15. 15. Relationship to :nth-child()
16. 16. Relationship to CSS counters
17. 17. Progressive enhancement with @supports
18. 18. Respecting reduced-motion preferences
19. 19. Testing a draft CSS feature
20. 20. Choosing sibling functions for the right design

CHAPTER 1 OF 20 · Back to contents

1. What sibling-index() returns

The short answer: sibling-index() resolves to the one-based inclusive index of the originating element among its element siblings. The governing rule is: The first element child has index 1, not 0.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The CSS Values and Units draft defines the function as an integer based on tree counting. It counts the originating element itself within the sibling sequence. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.list > * { --i: sibling-index(); }

Expected result and reasoning. The first element gets 1, the second 2, and so on in supporting implementations. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using JavaScript-style zero-based intuition shifts every formula by one. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: DOM child order and computed integer
• Variable to hold constant: the surrounding setup, so the comparison isolates what sibling-index() returns.
• Variable to change: insert a new first element
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a staggered card list. Apply what sibling-index() returns in a staggered card list. The central question is whether the same rule still governs after the context changes. sibling-index() resolves to the one-based inclusive index of the originating element among its element siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The first element child has index 1, not 0.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a navigation menu. Apply what sibling-index() returns in a navigation menu. The central question is whether the same rule still governs after the context changes. sibling-index() resolves to the one-based inclusive index of the originating element among its element siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The first element child has index 1, not 0.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a shadow-DOM component. Apply what sibling-index() returns in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. sibling-index() resolves to the one-based inclusive index of the originating element among its element siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The first element child has index 1, not 0.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a decorative pseudo-element. Apply what sibling-index() returns in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. sibling-index() resolves to the one-based inclusive index of the originating element among its element siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The first element child has index 1, not 0.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. For four child elements, write the four sibling-index values. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. They are 1,2,3,4. The inclusive wording means the current element counts in its own position. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask for a tiny DOM sketch before discussing visual effects. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Contents · Full contents · Next: What sibling-count() returns →

CHAPTER 2 OF 20 · Back to contents

2. What sibling-count() returns

The short answer: sibling-count() resolves to the total number of element children of the parent. The governing rule is: Every element sibling in the same parent context sees the same count.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The function returns an integer derived from the parent’s child element list, not the current element’s position. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.list > * { --n: sibling-count(); }

Expected result and reasoning. With four element children, each receives 4. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating count as “siblings excluding self” would produce 3 and contradict the draft definition. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: number of element children and computed value
• Variable to hold constant: the surrounding setup, so the comparison isolates what sibling-count() returns.
• Variable to change: add one child element
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a responsive gallery. Apply what sibling-count() returns in a responsive gallery. The central question is whether the same rule still governs after the context changes. sibling-count() resolves to the total number of element children of the parent. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Every element sibling in the same parent context sees the same count.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an inserted notification row. Apply what sibling-count() returns in an inserted notification row. The central question is whether the same rule still governs after the context changes. sibling-count() resolves to the total number of element children of the parent. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Every element sibling in the same parent context sees the same count.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reduced-motion stylesheet. Apply what sibling-count() returns in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. sibling-count() resolves to the total number of element children of the parent. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Every element sibling in the same parent context sees the same count.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system demo. Apply what sibling-count() returns in a design-system demo. The central question is whether the same rule still governs after the context changes. sibling-count() resolves to the total number of element children of the parent. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Every element sibling in the same parent context sees the same count.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. For one only child, predict sibling-count and sibling-index. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Both are 1: the parent has one element child, and that child occupies position one. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

The single-child case exposes off-by-one misunderstandings quickly. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: What sibling-index() returns · Full contents · Next: The functions return integers usable in calculations →

CHAPTER 3 OF 20 · Back to contents

3. The functions return integers usable in calculations

The short answer: Both functions produce integer values that can participate in CSS math. The governing rule is: Use them where the property grammar accepts the resulting calculation.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The integer can be multiplied by a time, length, angle or number inside calc-like expressions, subject to normal CSS type rules. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item { transition-delay: calc((sibling-index() - 1) * 80ms); }

Expected result and reasoning. Supporting browsers compute delays 0ms,80ms,160ms… because subtracting one converts the one-based index to an offset. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Writing sibling-index()*80ms starts the first item at 80ms, which may be unintended. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: computed property and resolved delay
• Variable to hold constant: the surrounding setup, so the comparison isolates the functions return integers usable in calculations.
• Variable to change: remove the – 1 offset
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a navigation menu. Apply the functions return integers usable in calculations in a navigation menu. The central question is whether the same rule still governs after the context changes. Both functions produce integer values that can participate in CSS math. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use them where the property grammar accepts the resulting calculation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a shadow-DOM component. Apply the functions return integers usable in calculations in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Both functions produce integer values that can participate in CSS math. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use them where the property grammar accepts the resulting calculation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a decorative pseudo-element. Apply the functions return integers usable in calculations in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Both functions produce integer values that can participate in CSS math. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use them where the property grammar accepts the resulting calculation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a staggered card list. Apply the functions return integers usable in calculations in a staggered card list. The central question is whether the same rule still governs after the context changes. Both functions produce integer values that can participate in CSS math. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use them where the property grammar accepts the resulting calculation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Predict delays for three items. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. They are 0ms,80ms,160ms with the offset expression. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Require both numeric sequence and intended visual meaning. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: What sibling-count() returns · Full contents · Next: DOM tree counting, not the flat tree →

CHAPTER 4 OF 20 · Back to contents

4. DOM tree counting, not the flat tree

The short answer: The draft specifies DOM tree counting rather than flattened rendering order. The governing rule is: Slots, shadow composition and visual reordering do not automatically redefine the sibling sequence.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Tree-counting notation explicitly states that sibling-index and sibling-count use the DOM tree, not the flat tree. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

<div class="list"><div>A</div><div>B</div><div>C</div></div>
<style>.list>div{order:-1;--i:sibling-index()}</style>

Expected result and reasoning. Changing visual flex order does not change DOM sibling indices. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Reading positions from the screen can misdiagnose a correct DOM-based result. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: DOM inspector order and computed custom property
• Variable to hold constant: the surrounding setup, so the comparison isolates dom tree counting, not the flat tree.
• Variable to change: change CSS order without moving nodes
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: an inserted notification row. Apply dom tree counting, not the flat tree in an inserted notification row. The central question is whether the same rule still governs after the context changes. The draft specifies DOM tree counting rather than flattened rendering order. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Slots, shadow composition and visual reordering do not automatically redefine the sibling sequence.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reduced-motion stylesheet. Apply dom tree counting, not the flat tree in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. The draft specifies DOM tree counting rather than flattened rendering order. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Slots, shadow composition and visual reordering do not automatically redefine the sibling sequence.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system demo. Apply dom tree counting, not the flat tree in a design-system demo. The central question is whether the same rule still governs after the context changes. The draft specifies DOM tree counting rather than flattened rendering order. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Slots, shadow composition and visual reordering do not automatically redefine the sibling sequence.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a responsive gallery. Apply dom tree counting, not the flat tree in a responsive gallery. The central question is whether the same rule still governs after the context changes. The draft specifies DOM tree counting rather than flattened rendering order. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Slots, shadow composition and visual reordering do not automatically redefine the sibling sequence.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Explain why visual first and sibling-index 1 need not name the same element. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The function follows DOM order; layout order is a separate stage. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Have the learner inspect markup and computed styles side by side. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: The functions return integers usable in calculations · Full contents · Next: Only element children contribute to the count →

CHAPTER 5 OF 20 · Back to contents

5. Only element children contribute to the count

The short answer: Text nodes and comments are not element children. The governing rule is: sibling-count counts child elements of the parent.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Whitespace text in HTML source does not add to the function’s total, even though it is a DOM node. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

<div class="list"> text <span>A</span><!--x--><span>B</span></div>

Expected result and reasoning. The two span elements participate; the text and comment do not make the count four. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Counting every DOM node confuses childNodes with children. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: parent.children length and markup
• Variable to hold constant: the surrounding setup, so the comparison isolates only element children contribute to the count.
• Variable to change: add a text node versus a span
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a shadow-DOM component. Apply only element children contribute to the count in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Text nodes and comments are not element children. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “sibling-count counts child elements of the parent.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a decorative pseudo-element. Apply only element children contribute to the count in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Text nodes and comments are not element children. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “sibling-count counts child elements of the parent.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a staggered card list. Apply only element children contribute to the count in a staggered card list. The central question is whether the same rule still governs after the context changes. Text nodes and comments are not element children. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “sibling-count counts child elements of the parent.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a navigation menu. Apply only element children contribute to the count in a navigation menu. The central question is whether the same rule still governs after the context changes. Text nodes and comments are not element children. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “sibling-count counts child elements of the parent.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Predict the count after adding whitespace and after adding another element. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Whitespace leaves the count unchanged; the element increases it by one. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Use browser devtools terminology precisely: children differs from childNodes. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: DOM tree counting, not the flat tree · Full contents · Next: A staggered delay without author-numbered variables →

CHAPTER 6 OF 20 · Back to contents

6. A staggered delay without author-numbered variables

The short answer: The index can remove repetitive per-item custom properties for simple DOM-order staggering. The governing rule is: Convert the one-based index to a zero-based delay offset when the first item should start immediately.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Each child calculates its own integer from the tree, so inserted elements update the sequence automatically. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item{animation-delay:calc((sibling-index() - 1)*60ms)}

Expected result and reasoning. Items receive increasing delays in DOM order on supporting browsers. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Claiming broad production support without feature checks is unsafe because the function is a developing feature. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: CSS.supports result, computed delay and prefers-reduced-motion
• Variable to hold constant: the surrounding setup, so the comparison isolates a staggered delay without author-numbered variables.
• Variable to change: insert a new second item
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a reduced-motion stylesheet. Apply a staggered delay without author-numbered variables in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. The index can remove repetitive per-item custom properties for simple DOM-order staggering. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Convert the one-based index to a zero-based delay offset when the first item should start immediately.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a design-system demo. Apply a staggered delay without author-numbered variables in a design-system demo. The central question is whether the same rule still governs after the context changes. The index can remove repetitive per-item custom properties for simple DOM-order staggering. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Convert the one-based index to a zero-based delay offset when the first item should start immediately.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a responsive gallery. Apply a staggered delay without author-numbered variables in a responsive gallery. The central question is whether the same rule still governs after the context changes. The index can remove repetitive per-item custom properties for simple DOM-order staggering. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Convert the one-based index to a zero-based delay offset when the first item should start immediately.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an inserted notification row. Apply a staggered delay without author-numbered variables in an inserted notification row. The central question is whether the same rule still governs after the context changes. The index can remove repetitive per-item custom properties for simple DOM-order staggering. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Convert the one-based index to a zero-based delay offset when the first item should start immediately.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compare author-maintained –i values with sibling-index for a dynamic list. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The function removes manual numbering, but progressive enhancement and motion preferences still govern deployment. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Frame this as a proposed enhancement, not a guaranteed service feature. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Only element children contribute to the count · Full contents · Next: Size progression by index →

CHAPTER 7 OF 20 · Back to contents

7. Size progression by index

The short answer: Index-derived values can create a controlled progression in size. The governing rule is: Keep bounds readable and avoid making later content unusably large.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Multiplying the offset by a small length produces predictable steps while preserving a baseline. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.tag{font-size:calc(1rem + (sibling-index() - 1)*0.08rem)}

Expected result and reasoning. Supporting browsers calculate 1rem,1.08rem,1.16rem… in DOM order. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using decorative progression on essential text without limits can harm readability. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: minimum, maximum and item count
• Variable to hold constant: the surrounding setup, so the comparison isolates size progression by index.
• Variable to change: increase sibling count to twenty
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a decorative pseudo-element. Apply size progression by index in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Index-derived values can create a controlled progression in size. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Keep bounds readable and avoid making later content unusably large.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a staggered card list. Apply size progression by index in a staggered card list. The central question is whether the same rule still governs after the context changes. Index-derived values can create a controlled progression in size. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Keep bounds readable and avoid making later content unusably large.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a navigation menu. Apply size progression by index in a navigation menu. The central question is whether the same rule still governs after the context changes. Index-derived values can create a controlled progression in size. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Keep bounds readable and avoid making later content unusably large.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a shadow-DOM component. Apply size progression by index in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Index-derived values can create a controlled progression in size. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Keep bounds readable and avoid making later content unusably large.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compute the final size for five and twenty items. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. For five it is 1.32rem; for twenty it is 2.52rem, showing why a clamp or different design may be needed. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask for worst-case arithmetic, not only a pretty three-item demo. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: A staggered delay without author-numbered variables · Full contents · Next: Reverse position from the end →

CHAPTER 8 OF 20 · Back to contents

8. Reverse position from the end

The short answer: sibling-count() – sibling-index() + 1 gives a one-based position from the end. The governing rule is: The final sibling has reverse position 1.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The formula subtracts the current one-based position from the total and restores inclusive counting. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item{--from-end:calc(sibling-count() - sibling-index() + 1)}

Expected result and reasoning. For four items, from-start 1,2,3,4 maps to from-end 4,3,2,1. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Omitting +1 gives 3,2,1,0 and changes the meaning. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: count, index and computed formula
• Variable to hold constant: the surrounding setup, so the comparison isolates reverse position from the end.
• Variable to change: remove +1 and rename the quantity honestly
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a design-system demo. Apply reverse position from the end in a design-system demo. The central question is whether the same rule still governs after the context changes. sibling-count() – sibling-index() + 1 gives a one-based position from the end. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The final sibling has reverse position 1.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a responsive gallery. Apply reverse position from the end in a responsive gallery. The central question is whether the same rule still governs after the context changes. sibling-count() – sibling-index() + 1 gives a one-based position from the end. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The final sibling has reverse position 1.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an inserted notification row. Apply reverse position from the end in an inserted notification row. The central question is whether the same rule still governs after the context changes. sibling-count() – sibling-index() + 1 gives a one-based position from the end. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The final sibling has reverse position 1.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reduced-motion stylesheet. Apply reverse position from the end in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. sibling-count() – sibling-index() + 1 gives a one-based position from the end. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “The final sibling has reverse position 1.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Calculate both formulas for the last element. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. The one-based reverse position is 1; the zero-based distance is 0. Both can be valid when named correctly. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Encourage variable names that encode the counting convention. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Size progression by index · Full contents · Next: Normalised progress across siblings →

CHAPTER 9 OF 20 · Back to contents

9. Normalised progress across siblings

The short answer: Index and count can form a 0-to-1 progress value when there are at least two siblings. The governing rule is: Use (index – 1)/(count – 1) and handle the single-child denominator.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The first item maps to zero and the last to one, which can drive colour or position interpolation. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item{--p:calc((sibling-index() - 1)/(sibling-count() - 1))}

Expected result and reasoning. With five items the values are 0,.25,.5,.75,1 in supporting math contexts. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A one-child list makes the denominator zero, so the formula needs a guarded design. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: count and computed value
• Variable to hold constant: the surrounding setup, so the comparison isolates normalised progress across siblings.
• Variable to change: test one, two and five children
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a staggered card list. Apply normalised progress across siblings in a staggered card list. The central question is whether the same rule still governs after the context changes. Index and count can form a 0-to-1 progress value when there are at least two siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use (index – 1)/(count – 1) and handle the single-child denominator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a navigation menu. Apply normalised progress across siblings in a navigation menu. The central question is whether the same rule still governs after the context changes. Index and count can form a 0-to-1 progress value when there are at least two siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use (index – 1)/(count – 1) and handle the single-child denominator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a shadow-DOM component. Apply normalised progress across siblings in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Index and count can form a 0-to-1 progress value when there are at least two siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use (index – 1)/(count – 1) and handle the single-child denominator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a decorative pseudo-element. Apply normalised progress across siblings in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Index and count can form a 0-to-1 progress value when there are at least two siblings. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use (index – 1)/(count – 1) and handle the single-child denominator.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Propose a safe design for a list that may contain one item. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use a default or conditional design that avoids division by zero; verify the exact property’s invalid-value behaviour in the target browser. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Edge counts are part of design, not an afterthought. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Reverse position from the end · Full contents · Next: Dynamic insertion updates positions →

CHAPTER 10 OF 20 · Back to contents

10. Dynamic insertion updates positions

The short answer: Because values derive from the current DOM tree, inserting an element changes later indices and the shared count. The governing rule is: Do not cache an old mental picture of positions after DOM mutation.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Style recalculation resolves the functions against the current tree in supporting implementations. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

list.insertBefore(document.createElement('li'), list.children[1]);

Expected result and reasoning. A new second element becomes index 2; former positions from 2 onward increase, and every sibling count increases by one. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Assuming only the inserted element changes misses dependent computed values. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: before/after computed custom properties
• Variable to hold constant: the surrounding setup, so the comparison isolates dynamic insertion updates positions.
• Variable to change: append at the end instead of inserting near the start
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a responsive gallery. Apply dynamic insertion updates positions in a responsive gallery. The central question is whether the same rule still governs after the context changes. Because values derive from the current DOM tree, inserting an element changes later indices and the shared count. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not cache an old mental picture of positions after DOM mutation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an inserted notification row. Apply dynamic insertion updates positions in an inserted notification row. The central question is whether the same rule still governs after the context changes. Because values derive from the current DOM tree, inserting an element changes later indices and the shared count. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not cache an old mental picture of positions after DOM mutation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reduced-motion stylesheet. Apply dynamic insertion updates positions in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. Because values derive from the current DOM tree, inserting an element changes later indices and the shared count. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not cache an old mental picture of positions after DOM mutation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system demo. Apply dynamic insertion updates positions in a design-system demo. The central question is whether the same rule still governs after the context changes. Because values derive from the current DOM tree, inserting an element changes later indices and the shared count. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not cache an old mental picture of positions after DOM mutation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compare changes caused by prepend, middle insert and append. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Prepend changes every index; middle insert changes following indices; append keeps existing indices but increases every count. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

This is useful practice in dependency reasoning. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Normalised progress across siblings · Full contents · Next: Removal has the inverse dependency pattern →

CHAPTER 11 OF 20 · Back to contents

11. Removal has the inverse dependency pattern

The short answer: Removing an element decreases the total and shifts following indices. The governing rule is: Re-evaluate formulas that use either count or index.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Even earlier siblings whose index stays the same can change styles if their formula uses sibling-count. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

list.children[1].remove();

Expected result and reasoning. Following siblings shift down one index; all remaining siblings observe a count reduced by one. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Looking only at index shifts misses count-based gradients or reverse positions on earlier elements. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: before/after values for all children
• Variable to hold constant: the surrounding setup, so the comparison isolates removal has the inverse dependency pattern.
• Variable to change: remove the final element versus the first
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a navigation menu. Apply removal has the inverse dependency pattern in a navigation menu. The central question is whether the same rule still governs after the context changes. Removing an element decreases the total and shifts following indices. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Re-evaluate formulas that use either count or index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a shadow-DOM component. Apply removal has the inverse dependency pattern in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Removing an element decreases the total and shifts following indices. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Re-evaluate formulas that use either count or index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a decorative pseudo-element. Apply removal has the inverse dependency pattern in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Removing an element decreases the total and shifts following indices. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Re-evaluate formulas that use either count or index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a staggered card list. Apply removal has the inverse dependency pattern in a staggered card list. The central question is whether the same rule still governs after the context changes. Removing an element decreases the total and shifts following indices. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Re-evaluate formulas that use either count or index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. List which values change for a count-only, index-only and combined formula. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Count-only changes for all; index-only changes for following siblings; combined may change for every sibling. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask the learner to trace dependencies rather than rely on visual inspection. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Dynamic insertion updates positions · Full contents · Next: Generated pseudo-elements and originating elements →

CHAPTER 12 OF 20 · Back to contents

12. Generated pseudo-elements and originating elements

The short answer: For pseudo-elements, the specification defines resolution using an originating or pseudo-element tree-counting context. The governing rule is: Identify which element the function is resolving for before predicting.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

CSS tree-counting functions include rules for pseudo-elements, including element-backed pseudo-elements that can participate in tree contexts. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item::before{content:counter(list-item);opacity:calc(sibling-index()/10)}

Expected result and reasoning. The exact resolution follows the originating-element rules in the draft; verify in a supporting implementation before production use. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Treating every pseudo-element as an independent DOM child is incorrect. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: computed style and selected pseudo-element
• Variable to hold constant: the surrounding setup, so the comparison isolates generated pseudo-elements and originating elements.
• Variable to change: move the function from ::before to the element itself
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: an inserted notification row. Apply generated pseudo-elements and originating elements in an inserted notification row. The central question is whether the same rule still governs after the context changes. For pseudo-elements, the specification defines resolution using an originating or pseudo-element tree-counting context. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Identify which element the function is resolving for before predicting.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reduced-motion stylesheet. Apply generated pseudo-elements and originating elements in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. For pseudo-elements, the specification defines resolution using an originating or pseudo-element tree-counting context. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Identify which element the function is resolving for before predicting.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system demo. Apply generated pseudo-elements and originating elements in a design-system demo. The central question is whether the same rule still governs after the context changes. For pseudo-elements, the specification defines resolution using an originating or pseudo-element tree-counting context. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Identify which element the function is resolving for before predicting.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a responsive gallery. Apply generated pseudo-elements and originating elements in a responsive gallery. The central question is whether the same rule still governs after the context changes. For pseudo-elements, the specification defines resolution using an originating or pseudo-element tree-counting context. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Identify which element the function is resolving for before predicting.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Compare values on the element and its ::before in a supporting browser. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use the specification’s originating-element model and record implementation status; do not invent a DOM node that is not there. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

This is an advanced chapter: accurate uncertainty is better than a false universal. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Removal has the inverse dependency pattern · Full contents · Next: Element-backed pseudo-elements can have their own tree context →

CHAPTER 13 OF 20 · Back to contents

13. Element-backed pseudo-elements can have their own tree context

The short answer: Some pseudo-elements are element-backed and may resolve tree-counting functions according to their defined pseudo-element tree. The governing rule is: Do not generalise ordinary ::before behaviour to every future or specialised pseudo-element.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The draft distinguishes cases and provides explicit tree-scoped resolution rules. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

Read the element-backed pseudo-elements can have their own tree context example once without executing it. Mark the exact input, the operation under study, and the expected observable result. Then write a one-sentence prediction. Only after that should the learner run the example. This order separates understanding from trial-and-error and makes any surprise diagnostically useful.

/* Experimental illustration */
::picker(select){ --i:sibling-index(); }

Expected result and reasoning. Results depend on the relevant pseudo-element model and browser implementation. The article does not claim universal support. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Copying an experimental selector into production without support evidence is not progressive enhancement. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: browser version, feature support and computed value
• Variable to hold constant: the surrounding setup, so the comparison isolates element-backed pseudo-elements can have their own tree context.
• Variable to change: use an ordinary element baseline
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a shadow-DOM component. Apply element-backed pseudo-elements can have their own tree context in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Some pseudo-elements are element-backed and may resolve tree-counting functions according to their defined pseudo-element tree. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not generalise ordinary ::before behaviour to every future or specialised pseudo-element.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a decorative pseudo-element. Apply element-backed pseudo-elements can have their own tree context in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Some pseudo-elements are element-backed and may resolve tree-counting functions according to their defined pseudo-element tree. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not generalise ordinary ::before behaviour to every future or specialised pseudo-element.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a staggered card list. Apply element-backed pseudo-elements can have their own tree context in a staggered card list. The central question is whether the same rule still governs after the context changes. Some pseudo-elements are element-backed and may resolve tree-counting functions according to their defined pseudo-element tree. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not generalise ordinary ::before behaviour to every future or specialised pseudo-element.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a navigation menu. Apply element-backed pseudo-elements can have their own tree context in a navigation menu. The central question is whether the same rule still governs after the context changes. Some pseudo-elements are element-backed and may resolve tree-counting functions according to their defined pseudo-element tree. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not generalise ordinary ::before behaviour to every future or specialised pseudo-element.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Write a test plan rather than a claimed universal result. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Create a minimal supported control, inspect computed styles, compare against an ordinary element, and record browser/version. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Teach learners how to investigate a draft feature responsibly. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Generated pseudo-elements and originating elements · Full contents · Next: Shadow-scoped references may resolve to zero →

CHAPTER 14 OF 20 · Back to contents

14. Shadow-scoped references may resolve to zero

The short answer: The draft includes a zero result when a tree-counting function is evaluated in a shadow-scoped reference that cannot refer to the originating element. The governing rule is: Zero is a scoped-resolution signal, not an ordinary one-based sibling index.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Tree scopes prevent some references from reaching an element. The specification defines zero so the function has an integer result in that case. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

/* Conceptual shadow-scoped fixture; verify in a supporting browser */
.item{--i:sibling-index()}

Expected result and reasoning. When the specified scoping condition applies, the draft says the result is 0. Otherwise normal one-based counting applies. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Calling zero “the first item” reverses the one-based rule. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: tree scope, originating element and computed integer
• Variable to hold constant: the surrounding setup, so the comparison isolates shadow-scoped references may resolve to zero.
• Variable to change: move the rule into the element’s reachable scope
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a reduced-motion stylesheet. Apply shadow-scoped references may resolve to zero in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. The draft includes a zero result when a tree-counting function is evaluated in a shadow-scoped reference that cannot refer to the originating element. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Zero is a scoped-resolution signal, not an ordinary one-based sibling index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a design-system demo. Apply shadow-scoped references may resolve to zero in a design-system demo. The central question is whether the same rule still governs after the context changes. The draft includes a zero result when a tree-counting function is evaluated in a shadow-scoped reference that cannot refer to the originating element. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Zero is a scoped-resolution signal, not an ordinary one-based sibling index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a responsive gallery. Apply shadow-scoped references may resolve to zero in a responsive gallery. The central question is whether the same rule still governs after the context changes. The draft includes a zero result when a tree-counting function is evaluated in a shadow-scoped reference that cannot refer to the originating element. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Zero is a scoped-resolution signal, not an ordinary one-based sibling index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: an inserted notification row. Apply shadow-scoped references may resolve to zero in an inserted notification row. The central question is whether the same rule still governs after the context changes. The draft includes a zero result when a tree-counting function is evaluated in a shadow-scoped reference that cannot refer to the originating element. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Zero is a scoped-resolution signal, not an ordinary one-based sibling index.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Explain why 0 must not be treated as a normal index. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Normal indices begin at 1; zero indicates the special unresolved scoped condition described by the draft. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

A good explanation labels the exceptional condition explicitly. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Element-backed pseudo-elements can have their own tree context · Full contents · Next: Relationship to :nth-child() →

CHAPTER 15 OF 20 · Back to contents

15. Relationship to :nth-child()

The short answer: Both concepts use sibling positions, but one selects elements while the other returns a numeric value for calculations. The governing rule is: Use :nth-child() for matching patterns and sibling-index() when a value is needed inside property computation.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Selectors decide whether a rule applies. Tree-counting functions contribute numbers after a rule applies. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item:nth-child(odd){font-weight:700}
.item{--i:sibling-index()}

Expected result and reasoning. :nth-child(odd) matches alternating items; –i records each one-based position in supporting browsers. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Replacing every nth-child selector with arithmetic can make simple matching harder to read. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

Use a four-pass diagnosis. Pass one: classify. Identify the kind of value or state being examined. Pass two: trace. Follow the operation in the order defined by the platform or specification. Pass three: observe. Capture a minimal output, not a screenshot of a large project. Pass four: contrast. Change one feature and run again. For this chapter, the highest-value question is: “Do I need to select a subset or calculate from every position?”

• Evidence to collect: matched elements and computed values
• Variable to hold constant: the surrounding setup, so the comparison isolates relationship to :nth-child().
• Variable to change: implement an odd/even effect both ways
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a decorative pseudo-element. Apply relationship to :nth-child() in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. Both concepts use sibling positions, but one selects elements while the other returns a numeric value for calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use :nth-child() for matching patterns and sibling-index() when a value is needed inside property computation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a staggered card list. Apply relationship to :nth-child() in a staggered card list. The central question is whether the same rule still governs after the context changes. Both concepts use sibling positions, but one selects elements while the other returns a numeric value for calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use :nth-child() for matching patterns and sibling-index() when a value is needed inside property computation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a navigation menu. Apply relationship to :nth-child() in a navigation menu. The central question is whether the same rule still governs after the context changes. Both concepts use sibling positions, but one selects elements while the other returns a numeric value for calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use :nth-child() for matching patterns and sibling-index() when a value is needed inside property computation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a shadow-DOM component. Apply relationship to :nth-child() in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. Both concepts use sibling positions, but one selects elements while the other returns a numeric value for calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Use :nth-child() for matching patterns and sibling-index() when a value is needed inside property computation.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Choose the clearer tool for zebra striping and for a continuous delay. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Use :nth-child for striping; use an index-derived calculation for a continuous progression. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Tool choice should follow the reader job, not novelty. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Shadow-scoped references may resolve to zero · Full contents · Next: Relationship to CSS counters →

CHAPTER 16 OF 20 · Back to contents

16. Relationship to CSS counters

The short answer: Counters generate or track textual numbering; sibling functions provide numeric tree positions for property calculations. The governing rule is: Do not assume a displayed counter value is interchangeable with a typed integer function.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Counters can be reset, incremented and formatted. sibling-index is tied to current element sibling order under the specified counting rules. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.list{counter-reset:item}.item{counter-increment:item}.item::before{content:counter(item)}

Expected result and reasoning. The counter can display 1,2,3, while sibling-index can drive delays; their similar visible numbers come from different mechanisms. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Using generated text as a numeric property input is not the same operation. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: generated content and computed numeric property
• Variable to hold constant: the surrounding setup, so the comparison isolates relationship to css counters.
• Variable to change: reset the counter midway
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a design-system demo. Apply relationship to css counters in a design-system demo. The central question is whether the same rule still governs after the context changes. Counters generate or track textual numbering; sibling functions provide numeric tree positions for property calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not assume a displayed counter value is interchangeable with a typed integer function.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a responsive gallery. Apply relationship to css counters in a responsive gallery. The central question is whether the same rule still governs after the context changes. Counters generate or track textual numbering; sibling functions provide numeric tree positions for property calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not assume a displayed counter value is interchangeable with a typed integer function.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: an inserted notification row. Apply relationship to css counters in an inserted notification row. The central question is whether the same rule still governs after the context changes. Counters generate or track textual numbering; sibling functions provide numeric tree positions for property calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not assume a displayed counter value is interchangeable with a typed integer function.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a reduced-motion stylesheet. Apply relationship to css counters in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. Counters generate or track textual numbering; sibling functions provide numeric tree positions for property calculations. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Do not assume a displayed counter value is interchangeable with a typed integer function.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Show a case where counter number differs from sibling-index. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. A counter reset can restart displayed numbering while sibling-index continues with DOM position. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Similar outputs do not prove identical semantics. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Relationship to :nth-child() · Full contents · Next: Progressive enhancement with @supports →

CHAPTER 17 OF 20 · Back to contents

17. Progressive enhancement with @supports

The short answer: A draft feature should enhance a usable baseline rather than make the interface depend on unverified support. The governing rule is: Provide stable default styles and gate the enhancement when feature detection is available and reliable.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Browsers that do not parse or support the function may invalidate the declaration, leaving earlier cascade values. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.item{transition-delay:0ms}
@supports (transition-delay:calc(sibling-index()*1ms)){.item{transition-delay:calc((sibling-index() - 1)*60ms)}}

Expected result and reasoning. Unsupported browsers retain the baseline delay; supporting browsers can apply the stagger. Verify feature-query behaviour in target browsers. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Putting essential visibility behind the experimental declaration can hide content. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: baseline rendering and feature-query result
• Variable to hold constant: the surrounding setup, so the comparison isolates progressive enhancement with @supports.
• Variable to change: disable the enhanced rule
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a staggered card list. Apply progressive enhancement with @supports in a staggered card list. The central question is whether the same rule still governs after the context changes. A draft feature should enhance a usable baseline rather than make the interface depend on unverified support. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Provide stable default styles and gate the enhancement when feature detection is available and reliable.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a navigation menu. Apply progressive enhancement with @supports in a navigation menu. The central question is whether the same rule still governs after the context changes. A draft feature should enhance a usable baseline rather than make the interface depend on unverified support. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Provide stable default styles and gate the enhancement when feature detection is available and reliable.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a shadow-DOM component. Apply progressive enhancement with @supports in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. A draft feature should enhance a usable baseline rather than make the interface depend on unverified support. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Provide stable default styles and gate the enhancement when feature detection is available and reliable.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a decorative pseudo-element. Apply progressive enhancement with @supports in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. A draft feature should enhance a usable baseline rather than make the interface depend on unverified support. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Provide stable default styles and gate the enhancement when feature detection is available and reliable.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Design a card list that remains readable with no sibling functions. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Keep layout, order and content independent of the enhancement; use the functions only for optional polish. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Parents should hear “works without it” before “looks nicer with it”. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Relationship to CSS counters · Full contents · Next: Respecting reduced-motion preferences →

CHAPTER 18 OF 20 · Back to contents

18. Respecting reduced-motion preferences

The short answer: Index-driven animation can multiply motion across many elements. The governing rule is: Pair decorative staggering with prefers-reduced-motion and a no-motion or reduced-motion baseline.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Accessibility preferences are a higher-level user constraint than the elegance of a counting formula. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

@media (prefers-reduced-motion:reduce){.item{animation:none;transition:none}}

Expected result and reasoning. Users requesting reduced motion receive the non-animated presentation. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Reducing only the delay while keeping large motion may not respect the preference. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: media emulation and final animations
• Variable to hold constant: the surrounding setup, so the comparison isolates respecting reduced-motion preferences.
• Variable to change: switch preference in devtools
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a responsive gallery. Apply respecting reduced-motion preferences in a responsive gallery. The central question is whether the same rule still governs after the context changes. Index-driven animation can multiply motion across many elements. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Pair decorative staggering with prefers-reduced-motion and a no-motion or reduced-motion baseline.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: an inserted notification row. Apply respecting reduced-motion preferences in an inserted notification row. The central question is whether the same rule still governs after the context changes. Index-driven animation can multiply motion across many elements. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Pair decorative staggering with prefers-reduced-motion and a no-motion or reduced-motion baseline.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a reduced-motion stylesheet. Apply respecting reduced-motion preferences in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. Index-driven animation can multiply motion across many elements. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Pair decorative staggering with prefers-reduced-motion and a no-motion or reduced-motion baseline.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a design-system demo. Apply respecting reduced-motion preferences in a design-system demo. The central question is whether the same rule still governs after the context changes. Index-driven animation can multiply motion across many elements. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Pair decorative staggering with prefers-reduced-motion and a no-motion or reduced-motion baseline.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Audit the staggered list in both preference modes. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Content order and visibility must remain intact; the reduced mode should remove or substantially reduce nonessential motion. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Treat this as part of correctness, not an optional afterthought. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Progressive enhancement with @supports · Full contents · Next: Testing a draft CSS feature →

CHAPTER 19 OF 20 · Back to contents

19. Testing a draft CSS feature

The short answer: A reliable test records browser version, flag state, minimal markup and computed values. The governing rule is: Visual resemblance alone is insufficient evidence of numeric resolution.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

Draft features can change and implementations can be partial. A tiny test page and computed-style capture make claims reproducible. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

const item=document.querySelector('.item');
console.log(getComputedStyle(item).getPropertyValue('--i'));

Expected result and reasoning. A supporting fixture should expose the resolved custom property or downstream computed value. An empty/invalid result requires careful interpretation. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. A screenshot of a stagger does not prove which function produced it. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: browser build, CSS.supports, computed style and DOM
• Variable to hold constant: the surrounding setup, so the comparison isolates testing a draft css feature.
• Variable to change: remove the function declaration while keeping baseline
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: a navigation menu. Apply testing a draft css feature in a navigation menu. The central question is whether the same rule still governs after the context changes. A reliable test records browser version, flag state, minimal markup and computed values. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Visual resemblance alone is insufficient evidence of numeric resolution.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a shadow-DOM component. Apply testing a draft css feature in a shadow-DOM component. The central question is whether the same rule still governs after the context changes. A reliable test records browser version, flag state, minimal markup and computed values. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Visual resemblance alone is insufficient evidence of numeric resolution.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a decorative pseudo-element. Apply testing a draft css feature in a decorative pseudo-element. The central question is whether the same rule still governs after the context changes. A reliable test records browser version, flag state, minimal markup and computed values. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Visual resemblance alone is insufficient evidence of numeric resolution.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a staggered card list. Apply testing a draft css feature in a staggered card list. The central question is whether the same rule still governs after the context changes. A reliable test records browser version, flag state, minimal markup and computed values. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Visual resemblance alone is insufficient evidence of numeric resolution.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Write a four-step verification checklist. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Record version; check parsing/support; inspect computed value for known DOM; then compare a controlled DOM mutation. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Save the HTML fixture with the article record so future reviews can repeat it. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Respecting reduced-motion preferences · Full contents · Next: Choosing sibling functions for the right design →

CHAPTER 20 OF 20 · Back to contents

20. Choosing sibling functions for the right design

The short answer: Use sibling-index and sibling-count for optional, DOM-order-derived numeric effects when current support and accessibility requirements are satisfied. The governing rule is: Reject them as the sole basis for essential ordering, hidden content or unsupported production logic.. This is the sentence a learner should be able to say before touching a keyboard. It turns a vague topic into a testable model and gives a parent or tutor something precise to listen for.

The strongest use cases remove repetitive author numbering while preserving a plain baseline. That mechanism matters because superficially similar examples can produce different results. A reliable explanation names the relevant object, identifies the operation performed on it, and states when the decision is made. “It works” is not enough; mastery means predicting the result and explaining why a nearby example behaves differently.

Worked example: predict before running

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

.chips>*{--hue:calc(200 + (sibling-index() - 1)*8);border-color:hsl(var(--hue) 60% 50%)}

Expected result and reasoning. A supporting browser gives a gentle DOM-order colour progression; a baseline border colour should precede it. The important evidence is not merely the printed value or exit status. It is the connection between that evidence and the rule above. Say the chain aloud: input → relevant rule → operation → observable result. If a learner cannot supply the middle two links, the right response is to revisit the model rather than add more examples.

Near miss. Choosing the feature merely because it is new can add compatibility cost without reader value. This is tempting because it uses a familiar word or visual resemblance. Correct it by changing only one variable at a time and comparing the two cases side by side. A good contrast preserves everything except the feature named in the rule.

Diagnostic route when the answer is wrong

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

• Evidence to collect: support matrix, accessibility review and fallback
• Variable to hold constant: the surrounding setup, so the comparison isolates choosing sibling functions for the right design.
• Variable to change: replace the dynamic list with a fixed three-item list
• Explanation standard: name the rule, not merely the successful command or copied syntax.

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

Four transfer cases

Transfer case 1: an inserted notification row. Apply choosing sibling functions for the right design in an inserted notification row. The central question is whether the same rule still governs after the context changes. Use sibling-index and sibling-count for optional, DOM-order-derived numeric effects when current support and accessibility requirements are satisfied. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Reject them as the sole basis for essential ordering, hidden content or unsupported production logic.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 2: a reduced-motion stylesheet. Apply choosing sibling functions for the right design in a reduced-motion stylesheet. The central question is whether the same rule still governs after the context changes. Use sibling-index and sibling-count for optional, DOM-order-derived numeric effects when current support and accessibility requirements are satisfied. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Reject them as the sole basis for essential ordering, hidden content or unsupported production logic.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 3: a design-system demo. Apply choosing sibling functions for the right design in a design-system demo. The central question is whether the same rule still governs after the context changes. Use sibling-index and sibling-count for optional, DOM-order-derived numeric effects when current support and accessibility requirements are satisfied. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Reject them as the sole basis for essential ordering, hidden content or unsupported production logic.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Transfer case 4: a responsive gallery. Apply choosing sibling functions for the right design in a responsive gallery. The central question is whether the same rule still governs after the context changes. Use sibling-index and sibling-count for optional, DOM-order-derived numeric effects when current support and accessibility requirements are satisfied. Preserve a tiny record of input, prediction and observed result so that an apparent exception can be investigated rather than guessed at. Start by naming the observable evidence, then apply the chapter rule “Reject them as the sole basis for essential ordering, hidden content or unsupported production logic.”. Do not jump straight to a command or syntax change. First predict the outcome, perform the smallest safe check, and compare the result with that prediction. This makes the case useful beyond the immediate exercise: the learner is practising a decision process, not memorising a one-off answer. If the result differs, record what changed—platform, input shape, repository state, document tree, or evaluation order—before revising the model.

Practice, pause point, and explained answer

Task. Decide between sibling functions, author-set –i and nth-child rules for dynamic cards. Before checking anything, write (1) the predicted result, (2) the rule that justifies it, and (3) one nearby variation that should change the result. A complete response should be understandable to someone who has not seen the example.

Explained answer. Sibling functions suit dynamic optional progression; author variables offer broader control/support; nth-child suits discrete patterns. The reasoning earns more attention than the final value. If the learner reached the correct result by guessing, repeat the task with the variation they proposed. If they can predict both cases and explain the contrast, the idea is beginning to transfer.

Parent and tutor decision point

Ask for a reasoned choice with fallback, not enthusiasm alone. A useful conversation is brief: ask for the rule, ask for a prediction, then ask which observation would disprove it. Avoid turning the exchange into a vocabulary quiz. The goal is to hear a causal explanation and see a controlled test. Praise a corrected prediction when the learner uses evidence well; that is stronger progress than protecting an unexamined first answer.

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

← Previous: Testing a draft CSS feature · Full contents · Parent guide →

Parent guide: what mastery looks like

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

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

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

Capstone practice with explained routes

Capstone 1: Rebuild the smallest trustworthy fixture

Scenario. Create a disposable CSS fixture that demonstrates tree-counting calculations without unrelated project code.

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

Explained resolution. The fixture is successful when another learner can reproduce the observation and explain the rule that separates the two cases. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 2: Diagnose a believable wrong explanation

Scenario. A learner has the correct output but explains it using the wrong mechanism.

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

Explained resolution. If the prediction based on the wrong mechanism fails and the rule-based prediction holds, the contrast exposes the misconception. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 3: Handle an environment boundary

Scenario. Two machines or runtimes produce different observations.

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

Explained resolution. A difference is not automatically an error. Use the primary source to identify versioned or environmental conditions, then retest. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 4: Design a parent check-in

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

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

Explained resolution. The learner demonstrates mastery by explaining the causal chain and revising from evidence, not by performing a long polished demo. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 5: Transfer into a larger project

Scenario. The isolated fixture works but the school or home project does not.

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

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

Capstone 6: Write a regression check

Scenario. The behaviour must remain understood after a future update.

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

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

Capstone 7: Explain a limitation honestly

Scenario. The chosen API or feature does not cover an important edge case.

Route. Name the limitation, show what evidence the tool does provide and identify a more authoritative route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. The final advice is bounded: it neither discards the useful tool nor stretches it into a guarantee it cannot make. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Capstone 8: Choose the right tool

Scenario. Several related methods or commands could appear to solve the same task.

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

Explained resolution. Select the tool whose contract matches those needs and state why at least one tempting alternative was rejected. A strong submission includes the result, the causal chain and a controlled contrasting case. It does not hide uncertainty: if platform, version or environment matters, state that boundary.

Frequently asked questions

Is CSS sibling-index() and sibling-count() mainly a syntax topic?

No. Syntax is only the visible handle. The durable skill is deciding what the operation means, predicting its boundary conditions, and collecting evidence that distinguishes one explanation from another.

How long should one practice session be?

A focused ten-to-twenty-minute session is enough for one rule, one worked example and one contrast. Stop when the learner can explain the causal chain; save the fixture for later retrieval rather than adding tired repetitions.

Should a learner memorise every edge case?

Memorise the central rule and know where to consult the primary reference. Edge cases should be organised by cause—platform, input type, evaluation order, document tree or repository state—rather than stored as an unconnected list.

What should a parent ask if they do not code?

Ask for a prediction, the rule behind it, the observation that would disprove it, and one changed case. Those questions reveal understanding without requiring the parent to know the final technical answer in advance.

When is copying an example acceptable?

Copying is useful for establishing a trusted baseline. It becomes learning only after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How can we tell a typing error from a conceptual error?

Run a known-good minimal fixture first. If that fixture fails, inspect setup and transcription. If it passes but the learner predicts the wrong outcome for a controlled variation, the misconception is conceptual.

Should practice happen in a large school project?

Not initially. Large projects contain too many moving parts. Begin in a disposable directory, tiny script or isolated HTML file, then transfer the verified rule into the larger task.

What belongs in revision notes?

Keep the rule in one sentence, a smallest successful example, a near miss, the observed output, the environment version and one diagnostic question. This compact record is more reusable than a page of copied prose.

What if different computers give different results?

Treat the difference as evidence. Record operating system, runtime or browser version, filesystem or repository state, and exact input. Then consult the versioned primary source before deciding that either result is wrong.

When should the learner move to a new topic?

Move on when they can explain the rule, predict two contrasting cases, diagnose a deliberately broken example and transfer the idea to a fresh context without step-by-step prompting.

References and verification notes

Primary technical source: CSS Values and Units Level 5 draft, tree-counting functions. The current editor’s draft defines one-based index, total element-child count, integer results, DOM-tree rather than flat-tree counting, pseudo-element rules and the shadow-scoped zero case.

The worked examples were checked with the current CSSWG draft plus static arithmetic and DOM dependency checks; experimental browser behaviour is labelled for target-browser verification rather than presented as universal support. The checks confirm the specific examples in this guide; they do not promise identical behaviour on an older version, a different operating system, a different browser implementation, or a repository with different state. Keep the version and environment with the saved fixture.

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