PUNGGOL TUITION · PRACTICAL MASTERY GUIDE

If a learner thinks “random” means unpredictable in every respect, CSS random() offers a better design lesson: the exact draw varies, but the interval, step, sharing relationship, fallback and accessibility boundary should all be deliberate.

The core model is that the CSS Values 5 draft defines a uniform value between inclusive minimum and maximum calculations, with an optional step and an optional random key controlling which calls share a base value. It is non-cryptographic, still developing, and must be introduced as progressive enhancement.

This guide treats CSS random() 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 editor’s draft, random values. 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 random() represents and continue in order to Maximum below minimum.

Diagnose a confusing result: Chapters 5–8. Begin with Compatible calculation types and continue in order to Stepped outcomes are uniform choices.

Build reliable examples: Chapters 9–12. Begin with Omitted key means maximum separation and continue in order to Property-scoped sharing.

Transfer to real work: Chapters 13–16. Begin with Property-index-scoped calls and continue in order to Randomness is not cryptography.

Decide and teach: Chapters 17–20. Begin with Reduced-motion and visual comfort and continue in order to Choosing random() for the right job.

Open the full 20-chapter index

1. 1. What random() represents
2. 2. Draft status comes first
3. 3. Inclusive minimum and maximum
4. 4. Maximum below minimum
5. 5. Compatible calculation types
6. 6. The optional step argument
7. 7. A step may not land on max
8. 8. Stepped outcomes are uniform choices
9. 9. Omitted key means maximum separation
10. 10. Named sharing with a dashed identifier
11. 11. Element-scoped sharing
12. 12. Property-scoped sharing
13. 13. Property-index-scoped calls
14. 14. Fixed base values are for resolved values and testing
15. 15. Evaluation uses cached base values
16. 16. Randomness is not cryptography
17. 17. Reduced-motion and visual comfort
18. 18. Fallbacks before enhancement
19. 19. Support testing is not design testing
20. 20. Choosing random() for the right job

CHAPTER 1 OF 20 · Back to contents

1. What random() represents

The short answer: CSS random() represents a numeric or dimensional value selected between declared limits. The governing rule is: The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.. 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 browser derives a base random value and maps it into the requested interval, optionally through a step. 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 random() represents 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.

.card { rotate: random(-3deg, 3deg); }

Expected result and reasoning. A supporting implementation chooses an angle from the inclusive interval; the exact observation is intentionally not predetermined. 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 an exact expected value for an unkeyed call misunderstands the 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: “Which properties of the result are predictable even when the exact value is not?”

• Evidence to collect: the exact input, environment version, observed result and the rule for what random() represents
• Variable to hold constant: the surrounding setup, so the comparison isolates what random() represents.
• Variable to change: replace the interval with 0deg to 0deg
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For what random() represents, 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 card gallery. Transfer what random() represents into a card gallery. Preserve the governing rule—The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.—while identifying what changes in this setting. CSS random() represents a numeric or dimensional value selected between declared limits. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.”. 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 design. Transfer what random() represents into a reduced-motion design. Preserve the governing rule—The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.—while identifying what changes in this setting. CSS random() represents a numeric or dimensional value selected between declared limits. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.”. 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 classroom demo. Transfer what random() represents into a classroom demo. Preserve the governing rule—The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.—while identifying what changes in this setting. CSS random() represents a numeric or dimensional value selected between declared limits. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.”. 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 background. Transfer what random() represents into a decorative background. Preserve the governing rule—The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.—while identifying what changes in this setting. CSS random() represents a numeric or dimensional value selected between declared limits. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes.”. 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. Rebuild the example for what random() represents, predict the result, then replace the interval with 0deg to 0deg. Explain both outcomes without relying on trial and error. 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 supporting implementation chooses an angle from the inclusive interval; the exact observation is intentionally not predetermined. The contrast is explained by this rule: The current CSS Values 5 draft defines a uniform distribution over the allowed outcomes. 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 name the evidence that matters for what random() represents, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 random() represents, 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: Draft status comes first →

CHAPTER 2 OF 20 · Back to contents

2. Draft status comes first

The short answer: CSS Values and Units Level 5 remains an editor’s draft and may change. The governing rule is: Target-browser testing and a readable fallback are part of correct use.. 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.

A conforming idea in a draft is not the same as universal production availability. 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 draft status comes first 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.

.card { rotate: 0deg; }
@supports (rotate: random(-1deg, 1deg)) { .card { rotate: random(-1deg, 1deg); } }

Expected result and reasoning. Unsupported browsers keep the deterministic rotation; supporting browsers may enhance 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. Removing the fallback because the syntax appears in a specification confuses standards work with deployed support. 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 does the page do when the declaration is rejected?”

• Evidence to collect: the exact input, environment version, observed result and the rule for draft status comes first
• Variable to hold constant: the surrounding setup, so the comparison isolates draft status comes first.
• Variable to change: disable the @supports block
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For draft status comes first, 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 celebration page. Transfer draft status comes first into a celebration page. Preserve the governing rule—Target-browser testing and a readable fallback are part of correct use.—while identifying what changes in this setting. CSS Values and Units Level 5 remains an editor’s draft and may change. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Target-browser testing and a readable fallback are part of correct use.”. 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 component library. Transfer draft status comes first into a component library. Preserve the governing rule—Target-browser testing and a readable fallback are part of correct use.—while identifying what changes in this setting. CSS Values and Units Level 5 remains an editor’s draft and may change. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Target-browser testing and a readable fallback are part of correct use.”. 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 browser-support test. Transfer draft status comes first into a browser-support test. Preserve the governing rule—Target-browser testing and a readable fallback are part of correct use.—while identifying what changes in this setting. CSS Values and Units Level 5 remains an editor’s draft and may change. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Target-browser testing and a readable fallback are part of correct use.”. 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 visual regression fixture. Transfer draft status comes first into a visual regression fixture. Preserve the governing rule—Target-browser testing and a readable fallback are part of correct use.—while identifying what changes in this setting. CSS Values and Units Level 5 remains an editor’s draft and may change. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Target-browser testing and a readable fallback are part of correct use.”. 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. Rebuild the example for draft status comes first, predict the result, then disable the @supports block. Explain both outcomes without relying on trial and error. 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. Unsupported browsers keep the deterministic rotation; supporting browsers may enhance it. The contrast is explained by this rule: Target-browser testing and a readable fallback are part of correct use. 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 name the evidence that matters for draft status comes first, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 draft status comes first, 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 random() represents · Full contents · Next: Inclusive minimum and maximum →

CHAPTER 3 OF 20 · Back to contents

3. Inclusive minimum and maximum

The short answer: Both limits are inclusive. The governing rule is: The result may equal either endpoint when the random mapping selects it.. 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 specification defines the range before optional stepping and does not make the maximum an exclusive programming-language bound. 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 inclusive minimum and maximum 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.

.box { width: random(100px, 200px); }

Expected result and reasoning. Every valid result lies from 100px through 200px, inclusive. 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. Teaching [min,max) from familiar APIs imports the wrong boundary 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: “Are both endpoint values permitted by the CSS contract?”

• Evidence to collect: the exact input, environment version, observed result and the rule for inclusive minimum and maximum
• Variable to hold constant: the surrounding setup, so the comparison isolates inclusive minimum and maximum.
• Variable to change: use fixed test bases representing 0 and 1 where supported by the draft
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For inclusive minimum and maximum, 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 design. Transfer inclusive minimum and maximum into a reduced-motion design. Preserve the governing rule—The result may equal either endpoint when the random mapping selects it.—while identifying what changes in this setting. Both limits are inclusive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The result may equal either endpoint when the random mapping selects it.”. 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 classroom demo. Transfer inclusive minimum and maximum into a classroom demo. Preserve the governing rule—The result may equal either endpoint when the random mapping selects it.—while identifying what changes in this setting. Both limits are inclusive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The result may equal either endpoint when the random mapping selects it.”. 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 background. Transfer inclusive minimum and maximum into a decorative background. Preserve the governing rule—The result may equal either endpoint when the random mapping selects it.—while identifying what changes in this setting. Both limits are inclusive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The result may equal either endpoint when the random mapping selects it.”. 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 card gallery. Transfer inclusive minimum and maximum into a card gallery. Preserve the governing rule—The result may equal either endpoint when the random mapping selects it.—while identifying what changes in this setting. Both limits are inclusive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The result may equal either endpoint when the random mapping selects it.”. 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. Rebuild the example for inclusive minimum and maximum, predict the result, then use fixed test bases representing 0 and 1 where supported by the draft. Explain both outcomes without relying on trial and error. 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. Every valid result lies from 100px through 200px, inclusive. The contrast is explained by this rule: The result may equal either endpoint when the random mapping selects it. 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 name the evidence that matters for inclusive minimum and maximum, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 inclusive minimum and maximum, 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: Draft status comes first · Full contents · Next: Maximum below minimum →

CHAPTER 4 OF 20 · Back to contents

4. Maximum below minimum

The short answer: When max is less than min, it behaves as if max equals min. The governing rule is: The function collapses to the minimum rather than swapping the arguments.. 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.

Range normalisation prevents a negative-width interval while preserving the author’s first bound. 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 maximum below minimum 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.

.box { width: random(200px, 100px); }

Expected result and reasoning. The draft says this behaves as if the maximum were 200px, producing 200px. 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 the browser sorts the bounds predicts a 100px–200px distribution that the draft does not define. 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 invalid order swap, fail or collapse?”

• Evidence to collect: the exact input, environment version, observed result and the rule for maximum below minimum
• Variable to hold constant: the surrounding setup, so the comparison isolates maximum below minimum.
• Variable to change: change max from 100px to 200px
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For maximum below minimum, 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 component library. Transfer maximum below minimum into a component library. Preserve the governing rule—The function collapses to the minimum rather than swapping the arguments.—while identifying what changes in this setting. When max is less than min, it behaves as if max equals min. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The function collapses to the minimum rather than swapping the arguments.”. 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 browser-support test. Transfer maximum below minimum into a browser-support test. Preserve the governing rule—The function collapses to the minimum rather than swapping the arguments.—while identifying what changes in this setting. When max is less than min, it behaves as if max equals min. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The function collapses to the minimum rather than swapping the arguments.”. 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 visual regression fixture. Transfer maximum below minimum into a visual regression fixture. Preserve the governing rule—The function collapses to the minimum rather than swapping the arguments.—while identifying what changes in this setting. When max is less than min, it behaves as if max equals min. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The function collapses to the minimum rather than swapping the arguments.”. 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 celebration page. Transfer maximum below minimum into a celebration page. Preserve the governing rule—The function collapses to the minimum rather than swapping the arguments.—while identifying what changes in this setting. When max is less than min, it behaves as if max equals min. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The function collapses to the minimum rather than swapping the arguments.”. 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. Rebuild the example for maximum below minimum, predict the result, then change max from 100px to 200px. Explain both outcomes without relying on trial and error. 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 draft says this behaves as if the maximum were 200px, producing 200px. The contrast is explained by this rule: The function collapses to the minimum rather than swapping the arguments. 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 name the evidence that matters for maximum below minimum, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 maximum below minimum, 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: Inclusive minimum and maximum · Full contents · Next: Compatible calculation types →

CHAPTER 5 OF 20 · Back to contents

5. Compatible calculation types

The short answer: The two limits and step must participate in a valid calculation for the property. The governing rule is: Randomness does not bypass CSS type checking.. 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.

random() is a math function, so dimensional compatibility and property grammar still govern the computed value. 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 compatible calculation types 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.

.box { margin-left: random(1rem, 4rem); }

Expected result and reasoning. A supporting browser can produce a valid length in the declared interval. 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. Mixing an angle minimum with a length maximum is not creative randomness; it is an invalid calculation. 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 the arguments resolve to compatible types accepted by the property?”

• Evidence to collect: the exact input, environment version, observed result and the rule for compatible calculation types
• Variable to hold constant: the surrounding setup, so the comparison isolates compatible calculation types.
• Variable to change: compare two lengths with a length-and-angle mismatch
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For compatible calculation types, 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 classroom demo. Transfer compatible calculation types into a classroom demo. Preserve the governing rule—Randomness does not bypass CSS type checking.—while identifying what changes in this setting. The two limits and step must participate in a valid calculation for the property. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Randomness does not bypass CSS type checking.”. 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 background. Transfer compatible calculation types into a decorative background. Preserve the governing rule—Randomness does not bypass CSS type checking.—while identifying what changes in this setting. The two limits and step must participate in a valid calculation for the property. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Randomness does not bypass CSS type checking.”. 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 card gallery. Transfer compatible calculation types into a card gallery. Preserve the governing rule—Randomness does not bypass CSS type checking.—while identifying what changes in this setting. The two limits and step must participate in a valid calculation for the property. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Randomness does not bypass CSS type checking.”. 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 design. Transfer compatible calculation types into a reduced-motion design. Preserve the governing rule—Randomness does not bypass CSS type checking.—while identifying what changes in this setting. The two limits and step must participate in a valid calculation for the property. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Randomness does not bypass CSS type checking.”. 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. Rebuild the example for compatible calculation types, predict the result, then compare two lengths with a length-and-angle mismatch. Explain both outcomes without relying on trial and error. 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 supporting browser can produce a valid length in the declared interval. The contrast is explained by this rule: Randomness does not bypass CSS type checking. 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 name the evidence that matters for compatible calculation types, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 compatible calculation types, 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: Maximum below minimum · Full contents · Next: The optional step argument →

CHAPTER 6 OF 20 · Back to contents

6. The optional step argument

The short answer: A fourth numeric argument limits outcomes to a step from the minimum. The governing rule is: Stepped results follow min + N × step within the interval.. 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 base random value selects among the finite permitted step positions rather than being rounded after a continuous choice. 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 optional step argument 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.

.chip { margin-left: random(0px, 40px, 10px); }

Expected result and reasoning. The ordinary outcomes are 0px, 10px, 20px, 30px and 40px. 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 the final argument as a maximum precision or percentage gives the wrong set. 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 every possible value be enumerated before rendering?”

• Evidence to collect: the exact input, environment version, observed result and the rule for the optional step argument
• Variable to hold constant: the surrounding setup, so the comparison isolates the optional step argument.
• Variable to change: change the step to 15px
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For the optional step argument, 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 browser-support test. Transfer the optional step argument into a browser-support test. Preserve the governing rule—Stepped results follow min + N × step within the interval.—while identifying what changes in this setting. A fourth numeric argument limits outcomes to a step from the minimum. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepped results follow min + N × step within the interval.”. 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 visual regression fixture. Transfer the optional step argument into a visual regression fixture. Preserve the governing rule—Stepped results follow min + N × step within the interval.—while identifying what changes in this setting. A fourth numeric argument limits outcomes to a step from the minimum. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepped results follow min + N × step within the interval.”. 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 celebration page. Transfer the optional step argument into a celebration page. Preserve the governing rule—Stepped results follow min + N × step within the interval.—while identifying what changes in this setting. A fourth numeric argument limits outcomes to a step from the minimum. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepped results follow min + N × step within the interval.”. 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 component library. Transfer the optional step argument into a component library. Preserve the governing rule—Stepped results follow min + N × step within the interval.—while identifying what changes in this setting. A fourth numeric argument limits outcomes to a step from the minimum. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepped results follow min + N × step within the interval.”. 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. Rebuild the example for the optional step argument, predict the result, then change the step to 15px. Explain both outcomes without relying on trial and error. 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 ordinary outcomes are 0px, 10px, 20px, 30px and 40px. The contrast is explained by this rule: Stepped results follow min + N × step within the interval. 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 name the evidence that matters for the optional step argument, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 optional step argument, 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: Compatible calculation types · Full contents · Next: A step may not land on max →

CHAPTER 7 OF 20 · Back to contents

7. A step may not land on max

The short answer: The maximum is not guaranteed to be an outcome when repeated steps do not reach it. The governing rule is: Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.. 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.

This differs from dividing the interval into a requested number of equal buckets. 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 step may not land on max 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.

.chip { margin-left: random(0px, 100px, 30px); }

Expected result and reasoning. The principal stepped values are 0px, 30px, 60px and 90px; 100px is not simply forced into the set. 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. Appending max as an extra choice biases the intended model. 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 min + N × step reach max?”

• Evidence to collect: the exact input, environment version, observed result and the rule for a step may not land on max
• Variable to hold constant: the surrounding setup, so the comparison isolates a step may not land on max.
• Variable to change: change the step to 25px
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For a step may not land on max, 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 background. Transfer a step may not land on max into a decorative background. Preserve the governing rule—Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.—while identifying what changes in this setting. The maximum is not guaranteed to be an outcome when repeated steps do not reach it. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.”. 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 card gallery. Transfer a step may not land on max into a card gallery. Preserve the governing rule—Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.—while identifying what changes in this setting. The maximum is not guaranteed to be an outcome when repeated steps do not reach it. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.”. 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 design. Transfer a step may not land on max into a reduced-motion design. Preserve the governing rule—Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.—while identifying what changes in this setting. The maximum is not guaranteed to be an outcome when repeated steps do not reach it. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.”. 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 classroom demo. Transfer a step may not land on max into a classroom demo. Preserve the governing rule—Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.—while identifying what changes in this setting. The maximum is not guaranteed to be an outcome when repeated steps do not reach it. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules.”. 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. Rebuild the example for a step may not land on max, predict the result, then change the step to 25px. Explain both outcomes without relying on trial and error. 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 principal stepped values are 0px, 30px, 60px and 90px; 100px is not simply forced into the set. The contrast is explained by this rule: Stepping begins at min; the endpoint is included only when the step sequence lands sufficiently on it under the specification rules. 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 name the evidence that matters for a step may not land on max, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 step may not land on max, 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 optional step argument · Full contents · Next: Stepped outcomes are uniform choices →

CHAPTER 8 OF 20 · Back to contents

8. Stepped outcomes are uniform choices

The short answer: The allowed stepped positions are selected uniformly. The governing rule is: A stepped random() is not a continuous draw followed by ordinary rounding.. 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.

Selecting an integer position from the permitted set avoids giving interior bins different widths than edge bins. 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 stepped outcomes are uniform choices 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.

.dot { --n: random(0, 4, 1); }

Expected result and reasoning. The integer outcomes 0, 1, 2, 3 and 4 are the intended finite set. 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. Simulating with round(random(0,4)) would create a different probability model. 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 actual sample space?”

• Evidence to collect: the exact input, environment version, observed result and the rule for stepped outcomes are uniform choices
• Variable to hold constant: the surrounding setup, so the comparison isolates stepped outcomes are uniform choices.
• Variable to change: write the five outcomes before considering frequency
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For stepped outcomes are uniform choices, 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 visual regression fixture. Transfer stepped outcomes are uniform choices into a visual regression fixture. Preserve the governing rule—A stepped random() is not a continuous draw followed by ordinary rounding.—while identifying what changes in this setting. The allowed stepped positions are selected uniformly. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A stepped random() is not a continuous draw followed by ordinary rounding.”. 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 celebration page. Transfer stepped outcomes are uniform choices into a celebration page. Preserve the governing rule—A stepped random() is not a continuous draw followed by ordinary rounding.—while identifying what changes in this setting. The allowed stepped positions are selected uniformly. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A stepped random() is not a continuous draw followed by ordinary rounding.”. 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 component library. Transfer stepped outcomes are uniform choices into a component library. Preserve the governing rule—A stepped random() is not a continuous draw followed by ordinary rounding.—while identifying what changes in this setting. The allowed stepped positions are selected uniformly. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A stepped random() is not a continuous draw followed by ordinary rounding.”. 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 browser-support test. Transfer stepped outcomes are uniform choices into a browser-support test. Preserve the governing rule—A stepped random() is not a continuous draw followed by ordinary rounding.—while identifying what changes in this setting. The allowed stepped positions are selected uniformly. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A stepped random() is not a continuous draw followed by ordinary rounding.”. 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. Rebuild the example for stepped outcomes are uniform choices, predict the result, then write the five outcomes before considering frequency. Explain both outcomes without relying on trial and error. 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 integer outcomes 0, 1, 2, 3 and 4 are the intended finite set. The contrast is explained by this rule: A stepped random() is not a continuous draw followed by ordinary rounding. 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 name the evidence that matters for stepped outcomes are uniform choices, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 stepped outcomes are uniform choices, 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 step may not land on max · Full contents · Next: Omitted key means maximum separation →

CHAPTER 9 OF 20 · Back to contents

9. Omitted key means maximum separation

The short answer: With auto or no key, values vary across instances, properties and elements as much as possible. The governing rule is: Omitted key behaves as auto.. 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 random cache name includes element, property and position information so separate calls do not intentionally share a base value. 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 omitted key means maximum separation 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.

.box { width: random(100px,200px); height: random(100px,200px); }

Expected result and reasoning. Supporting browsers may produce different width and height on each element. 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. Expecting squares because both calls have identical bounds ignores cache-key semantics. 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: “Are these calls intended to share a random base value?”

• Evidence to collect: the exact input, environment version, observed result and the rule for omitted key means maximum separation
• Variable to hold constant: the surrounding setup, so the comparison isolates omitted key means maximum separation.
• Variable to change: supply the same named key to both calls
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For omitted key means maximum separation, 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 card gallery. Transfer omitted key means maximum separation into a card gallery. Preserve the governing rule—Omitted key behaves as auto.—while identifying what changes in this setting. With auto or no key, values vary across instances, properties and elements as much as possible. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Omitted key behaves as auto.”. 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 design. Transfer omitted key means maximum separation into a reduced-motion design. Preserve the governing rule—Omitted key behaves as auto.—while identifying what changes in this setting. With auto or no key, values vary across instances, properties and elements as much as possible. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Omitted key behaves as auto.”. 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 classroom demo. Transfer omitted key means maximum separation into a classroom demo. Preserve the governing rule—Omitted key behaves as auto.—while identifying what changes in this setting. With auto or no key, values vary across instances, properties and elements as much as possible. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Omitted key behaves as auto.”. 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 background. Transfer omitted key means maximum separation into a decorative background. Preserve the governing rule—Omitted key behaves as auto.—while identifying what changes in this setting. With auto or no key, values vary across instances, properties and elements as much as possible. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Omitted key behaves as auto.”. 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. Rebuild the example for omitted key means maximum separation, predict the result, then supply the same named key to both calls. Explain both outcomes without relying on trial and error. 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. Supporting browsers may produce different width and height on each element. The contrast is explained by this rule: Omitted key behaves as auto. 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 name the evidence that matters for omitted key means maximum separation, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 omitted key means maximum separation, 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: Stepped outcomes are uniform choices · Full contents · Next: Named sharing with a dashed identifier →

CHAPTER 10 OF 20 · Back to contents

10. Named sharing with a dashed identifier

The short answer: The same dashed identifier shares a base value across matching calls. The governing rule is: A named random cache key coordinates outcomes without making the numeric ranges identical.. 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 call maps the shared base value into its own range, allowing correlated design decisions. 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 named sharing with a dashed identifier 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.

.box { width: random(--shape,100px,200px); height: random(--shape,100px,200px); }

Expected result and reasoning. With identical bounds, the two properties use the same mapped value and form squares. 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 –shape a random seed promises repeatability beyond the document cache contract. 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 key coordinating calls or guaranteeing the same value across page loads?”

• Evidence to collect: the exact input, environment version, observed result and the rule for named sharing with a dashed identifier
• Variable to hold constant: the surrounding setup, so the comparison isolates named sharing with a dashed identifier.
• Variable to change: keep the key but give height a different range
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For named sharing with a dashed identifier, 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 celebration page. Transfer named sharing with a dashed identifier into a celebration page. Preserve the governing rule—A named random cache key coordinates outcomes without making the numeric ranges identical.—while identifying what changes in this setting. The same dashed identifier shares a base value across matching calls. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A named random cache key coordinates outcomes without making the numeric ranges identical.”. 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 component library. Transfer named sharing with a dashed identifier into a component library. Preserve the governing rule—A named random cache key coordinates outcomes without making the numeric ranges identical.—while identifying what changes in this setting. The same dashed identifier shares a base value across matching calls. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A named random cache key coordinates outcomes without making the numeric ranges identical.”. 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 browser-support test. Transfer named sharing with a dashed identifier into a browser-support test. Preserve the governing rule—A named random cache key coordinates outcomes without making the numeric ranges identical.—while identifying what changes in this setting. The same dashed identifier shares a base value across matching calls. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A named random cache key coordinates outcomes without making the numeric ranges identical.”. 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 visual regression fixture. Transfer named sharing with a dashed identifier into a visual regression fixture. Preserve the governing rule—A named random cache key coordinates outcomes without making the numeric ranges identical.—while identifying what changes in this setting. The same dashed identifier shares a base value across matching calls. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “A named random cache key coordinates outcomes without making the numeric ranges identical.”. 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. Rebuild the example for named sharing with a dashed identifier, predict the result, then keep the key but give height a different range. Explain both outcomes without relying on trial and error. 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. With identical bounds, the two properties use the same mapped value and form squares. The contrast is explained by this rule: A named random cache key coordinates outcomes without making the numeric ranges identical. 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 name the evidence that matters for named sharing with a dashed identifier, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 named sharing with a dashed identifier, 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: Omitted key means maximum separation · Full contents · Next: Element-scoped sharing →

CHAPTER 11 OF 20 · Back to contents

11. Element-scoped sharing

The short answer: element-scoped shares calls on one element but separates different elements. The governing rule is: Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.. 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 cache scope is declarative: calls resolving for the same element use the same base; another element gets another base. 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-scoped sharing 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.

.box { width: random(element-scoped,100px,200px); height: random(element-scoped,100px,200px); }

Expected result and reasoning. Each box can be a different-sized square, because its width and height share while boxes do not. 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 a plain global dashed name would make all boxes share one base. 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 boundary defines sameness: document or element?”

• Evidence to collect: the exact input, environment version, observed result and the rule for element-scoped sharing
• Variable to hold constant: the surrounding setup, so the comparison isolates element-scoped sharing.
• Variable to change: compare element-scoped with –global
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For element-scoped sharing, 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 design. Transfer element-scoped sharing into a reduced-motion design. Preserve the governing rule—Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.—while identifying what changes in this setting. element-scoped shares calls on one element but separates different elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.”. 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 classroom demo. Transfer element-scoped sharing into a classroom demo. Preserve the governing rule—Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.—while identifying what changes in this setting. element-scoped shares calls on one element but separates different elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.”. 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 background. Transfer element-scoped sharing into a decorative background. Preserve the governing rule—Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.—while identifying what changes in this setting. element-scoped shares calls on one element but separates different elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.”. 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 card gallery. Transfer element-scoped sharing into a card gallery. Preserve the governing rule—Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.—while identifying what changes in this setting. element-scoped shares calls on one element but separates different elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings.”. 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. Rebuild the example for element-scoped sharing, predict the result, then compare element-scoped with –global. Explain both outcomes without relying on trial and error. 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. Each box can be a different-sized square, because its width and height share while boxes do not. The contrast is explained by this rule: Add element identity to the cache name when each component should be internally coordinated yet distinct from its siblings. 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 name the evidence that matters for element-scoped sharing, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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-scoped sharing, 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: Named sharing with a dashed identifier · Full contents · Next: Property-scoped sharing →

CHAPTER 12 OF 20 · Back to contents

12. Property-scoped sharing

The short answer: property-scoped separates values by property while sharing that property across elements. The governing rule is: Use property scope when all widths should correlate and all heights should correlate independently.. 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 property name becomes part of the cache name, while element identity does not. 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 property-scoped sharing 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.

.box { width: random(property-scoped,100px,200px); height: random(property-scoped,100px,200px); }

Expected result and reasoning. All boxes share one width result and one height result; width and height need not match. 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. Expecting per-element variety contradicts the omitted element scope. 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 property name participates in the cache?”

• Evidence to collect: the exact input, environment version, observed result and the rule for property-scoped sharing
• Variable to hold constant: the surrounding setup, so the comparison isolates property-scoped sharing.
• Variable to change: add element-scoped to the key
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For property-scoped sharing, 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 component library. Transfer property-scoped sharing into a component library. Preserve the governing rule—Use property scope when all widths should correlate and all heights should correlate independently.—while identifying what changes in this setting. property-scoped separates values by property while sharing that property across elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use property scope when all widths should correlate and all heights should correlate independently.”. 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 browser-support test. Transfer property-scoped sharing into a browser-support test. Preserve the governing rule—Use property scope when all widths should correlate and all heights should correlate independently.—while identifying what changes in this setting. property-scoped separates values by property while sharing that property across elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use property scope when all widths should correlate and all heights should correlate independently.”. 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 visual regression fixture. Transfer property-scoped sharing into a visual regression fixture. Preserve the governing rule—Use property scope when all widths should correlate and all heights should correlate independently.—while identifying what changes in this setting. property-scoped separates values by property while sharing that property across elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use property scope when all widths should correlate and all heights should correlate independently.”. 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 celebration page. Transfer property-scoped sharing into a celebration page. Preserve the governing rule—Use property scope when all widths should correlate and all heights should correlate independently.—while identifying what changes in this setting. property-scoped separates values by property while sharing that property across elements. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use property scope when all widths should correlate and all heights should correlate independently.”. 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. Rebuild the example for property-scoped sharing, predict the result, then add element-scoped to the key. Explain both outcomes without relying on trial and error. 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. All boxes share one width result and one height result; width and height need not match. The contrast is explained by this rule: Use property scope when all widths should correlate and all heights should correlate independently. 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 name the evidence that matters for property-scoped sharing, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 property-scoped sharing, 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-scoped sharing · Full contents · Next: Property-index-scoped calls →

CHAPTER 13 OF 20 · Back to contents

13. Property-index-scoped calls

The short answer: property-index-scoped distinguishes multiple random functions in the same property value. The governing rule is: Function position can be part of the cache name.. 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 index is assigned before shorthand expansion, so two calls inside one declaration can be intentionally separated. 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 property-index-scoped calls 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.

.box { translate: random(property-index-scoped,-10px,10px) random(property-index-scoped,-10px,10px); }

Expected result and reasoning. The two axes use distinct cache names even though they are in the same property. 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 identical syntax forces identical axes ignores the index scope. 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: “How many random-function instances occur in the value, and what are their indexes?”

• Evidence to collect: the exact input, environment version, observed result and the rule for property-index-scoped calls
• Variable to hold constant: the surrounding setup, so the comparison isolates property-index-scoped calls.
• Variable to change: replace property-index-scoped with a shared dashed name
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For property-index-scoped calls, 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 classroom demo. Transfer property-index-scoped calls into a classroom demo. Preserve the governing rule—Function position can be part of the cache name.—while identifying what changes in this setting. property-index-scoped distinguishes multiple random functions in the same property value. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Function position can be part of the cache name.”. 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 background. Transfer property-index-scoped calls into a decorative background. Preserve the governing rule—Function position can be part of the cache name.—while identifying what changes in this setting. property-index-scoped distinguishes multiple random functions in the same property value. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Function position can be part of the cache name.”. 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 card gallery. Transfer property-index-scoped calls into a card gallery. Preserve the governing rule—Function position can be part of the cache name.—while identifying what changes in this setting. property-index-scoped distinguishes multiple random functions in the same property value. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Function position can be part of the cache name.”. 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 design. Transfer property-index-scoped calls into a reduced-motion design. Preserve the governing rule—Function position can be part of the cache name.—while identifying what changes in this setting. property-index-scoped distinguishes multiple random functions in the same property value. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Function position can be part of the cache name.”. 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. Rebuild the example for property-index-scoped calls, predict the result, then replace property-index-scoped with a shared dashed name. Explain both outcomes without relying on trial and error. 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 two axes use distinct cache names even though they are in the same property. The contrast is explained by this rule: Function position can be part of the cache name. 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 name the evidence that matters for property-index-scoped calls, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 property-index-scoped calls, 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: Property-scoped sharing · Full contents · Next: Fixed base values are for resolved values and testing →

CHAPTER 14 OF 20 · Back to contents

14. Fixed base values are for resolved values and testing

The short answer: The draft defines fixed followed by a number from 0 to 1 as a base value form. The governing rule is: Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.. 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 specification notes that fixed is not intended for authors, though it can appear in computed values; it is useful for understanding range mapping. 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 fixed base values are for resolved values and testing 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.

.box { width: random(fixed .25,100px,200px); }

Expected result and reasoning. The result maps a deterministic quarter-position base through the range under the draft algorithm. 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. Shipping fixed values while claiming visual randomness contradicts the purpose. 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 a test of mapping or a production request for variation?”

• Evidence to collect: the exact input, environment version, observed result and the rule for fixed base values are for resolved values and testing
• Variable to hold constant: the surrounding setup, so the comparison isolates fixed base values are for resolved values and testing.
• Variable to change: compare fixed 0 with fixed 1
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For fixed base values are for resolved values and testing, 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 browser-support test. Transfer fixed base values are for resolved values and testing into a browser-support test. Preserve the governing rule—Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.—while identifying what changes in this setting. The draft defines fixed followed by a number from 0 to 1 as a base value form. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.”. 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 visual regression fixture. Transfer fixed base values are for resolved values and testing into a visual regression fixture. Preserve the governing rule—Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.—while identifying what changes in this setting. The draft defines fixed followed by a number from 0 to 1 as a base value form. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.”. 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 celebration page. Transfer fixed base values are for resolved values and testing into a celebration page. Preserve the governing rule—Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.—while identifying what changes in this setting. The draft defines fixed followed by a number from 0 to 1 as a base value form. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.”. 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 component library. Transfer fixed base values are for resolved values and testing into a component library. Preserve the governing rule—Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.—while identifying what changes in this setting. The draft defines fixed followed by a number from 0 to 1 as a base value form. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness.”. 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. Rebuild the example for fixed base values are for resolved values and testing, predict the result, then compare fixed 0 with fixed 1. Explain both outcomes without relying on trial and error. 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 result maps a deterministic quarter-position base through the range under the draft algorithm. The contrast is explained by this rule: Treat fixed as a deterministic diagnostic, not ordinary author-facing randomness. 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 name the evidence that matters for fixed base values are for resolved values and testing, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 fixed base values are for resolved values and testing, 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: Property-index-scoped calls · Full contents · Next: Evaluation uses cached base values →

CHAPTER 15 OF 20 · Back to contents

15. Evaluation uses cached base values

The short answer: CSS declarations can be evaluated more than once without producing a new surprise each time. The governing rule is: The same random cache name returns the same random base value.. 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.

Caching reconciles declarative reevaluation with stable computed styling. 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 evaluation uses cached base values 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.

.box { --x: random(--stable,0,100); left: calc(var(--x) * 1px); }

Expected result and reasoning. Repeated evaluation with the same cache name preserves the same base value for the relevant document state. 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. Imagining a new draw on every paint would predict visual flicker the cache model is designed to avoid. 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 identifies the cache entry?”

• Evidence to collect: the exact input, environment version, observed result and the rule for evaluation uses cached base values
• Variable to hold constant: the surrounding setup, so the comparison isolates evaluation uses cached base values.
• Variable to change: change the key name from –stable to –other
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For evaluation uses cached base values, 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 background. Transfer evaluation uses cached base values into a decorative background. Preserve the governing rule—The same random cache name returns the same random base value.—while identifying what changes in this setting. CSS declarations can be evaluated more than once without producing a new surprise each time. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same random cache name returns the same random base value.”. 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 card gallery. Transfer evaluation uses cached base values into a card gallery. Preserve the governing rule—The same random cache name returns the same random base value.—while identifying what changes in this setting. CSS declarations can be evaluated more than once without producing a new surprise each time. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same random cache name returns the same random base value.”. 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 design. Transfer evaluation uses cached base values into a reduced-motion design. Preserve the governing rule—The same random cache name returns the same random base value.—while identifying what changes in this setting. CSS declarations can be evaluated more than once without producing a new surprise each time. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same random cache name returns the same random base value.”. 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 classroom demo. Transfer evaluation uses cached base values into a classroom demo. Preserve the governing rule—The same random cache name returns the same random base value.—while identifying what changes in this setting. CSS declarations can be evaluated more than once without producing a new surprise each time. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The same random cache name returns the same random base value.”. 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. Rebuild the example for evaluation uses cached base values, predict the result, then change the key name from –stable to –other. Explain both outcomes without relying on trial and error. 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. Repeated evaluation with the same cache name preserves the same base value for the relevant document state. The contrast is explained by this rule: The same random cache name returns the same random base value. 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 name the evidence that matters for evaluation uses cached base values, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 evaluation uses cached base values, 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: Fixed base values are for resolved values and testing · Full contents · Next: Randomness is not cryptography →

CHAPTER 16 OF 20 · Back to contents

16. Randomness is not cryptography

The short answer: The random-number method is user-agent-defined and not specified for cryptographic strength. The governing rule is: Never use CSS random functions for secrets, tokens, fairness or security decisions.. 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.

A visual-design primitive exposes no security guarantees, audit trail or trusted entropy contract. 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 randomness is not cryptography 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.

.decorative { rotate: random(-2deg,2deg); }

Expected result and reasoning. This is an appropriate decorative use; it does not decide access or generate a password. 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. Hiding a value in CSS does not make it secure. 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: “Would a weak or predictable generator harm a person, account or decision?”

• Evidence to collect: the exact input, environment version, observed result and the rule for randomness is not cryptography
• Variable to hold constant: the surrounding setup, so the comparison isolates randomness is not cryptography.
• Variable to change: move any security-sensitive decision to trusted application code
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For randomness is not cryptography, 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 visual regression fixture. Transfer randomness is not cryptography into a visual regression fixture. Preserve the governing rule—Never use CSS random functions for secrets, tokens, fairness or security decisions.—while identifying what changes in this setting. The random-number method is user-agent-defined and not specified for cryptographic strength. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Never use CSS random functions for secrets, tokens, fairness or security decisions.”. 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 celebration page. Transfer randomness is not cryptography into a celebration page. Preserve the governing rule—Never use CSS random functions for secrets, tokens, fairness or security decisions.—while identifying what changes in this setting. The random-number method is user-agent-defined and not specified for cryptographic strength. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Never use CSS random functions for secrets, tokens, fairness or security decisions.”. 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 component library. Transfer randomness is not cryptography into a component library. Preserve the governing rule—Never use CSS random functions for secrets, tokens, fairness or security decisions.—while identifying what changes in this setting. The random-number method is user-agent-defined and not specified for cryptographic strength. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Never use CSS random functions for secrets, tokens, fairness or security decisions.”. 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 browser-support test. Transfer randomness is not cryptography into a browser-support test. Preserve the governing rule—Never use CSS random functions for secrets, tokens, fairness or security decisions.—while identifying what changes in this setting. The random-number method is user-agent-defined and not specified for cryptographic strength. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Never use CSS random functions for secrets, tokens, fairness or security decisions.”. 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. Rebuild the example for randomness is not cryptography, predict the result, then move any security-sensitive decision to trusted application code. Explain both outcomes without relying on trial and error. 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. This is an appropriate decorative use; it does not decide access or generate a password. The contrast is explained by this rule: Never use CSS random functions for secrets, tokens, fairness or security decisions. 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 name the evidence that matters for randomness is not cryptography, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 randomness is not cryptography, 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: Evaluation uses cached base values · Full contents · Next: Reduced-motion and visual comfort →

CHAPTER 17 OF 20 · Back to contents

17. Reduced-motion and visual comfort

The short answer: Random variation can become distracting when attached to motion, scale or repeated animation. The governing rule is: Respect user preferences and keep randomness subordinate to readability.. 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.

A technically valid range can still create a poor learning page if motion competes with content. 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 reduced-motion and visual comfort 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.

.spark { animation-delay: random(0s,1s); }
@media (prefers-reduced-motion: reduce) { .spark { animation: none; } }

Expected result and reasoning. Users requesting reduced motion receive the deterministic 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. Random delays do not neutralise an excessive animation. 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 learner still read and navigate when enhancement is removed?”

• Evidence to collect: the exact input, environment version, observed result and the rule for reduced-motion and visual comfort
• Variable to hold constant: the surrounding setup, so the comparison isolates reduced-motion and visual comfort.
• Variable to change: test the reduced-motion media query
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For reduced-motion and visual comfort, 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 card gallery. Transfer reduced-motion and visual comfort into a card gallery. Preserve the governing rule—Respect user preferences and keep randomness subordinate to readability.—while identifying what changes in this setting. Random variation can become distracting when attached to motion, scale or repeated animation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Respect user preferences and keep randomness subordinate to readability.”. 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 design. Transfer reduced-motion and visual comfort into a reduced-motion design. Preserve the governing rule—Respect user preferences and keep randomness subordinate to readability.—while identifying what changes in this setting. Random variation can become distracting when attached to motion, scale or repeated animation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Respect user preferences and keep randomness subordinate to readability.”. 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 classroom demo. Transfer reduced-motion and visual comfort into a classroom demo. Preserve the governing rule—Respect user preferences and keep randomness subordinate to readability.—while identifying what changes in this setting. Random variation can become distracting when attached to motion, scale or repeated animation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Respect user preferences and keep randomness subordinate to readability.”. 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 background. Transfer reduced-motion and visual comfort into a decorative background. Preserve the governing rule—Respect user preferences and keep randomness subordinate to readability.—while identifying what changes in this setting. Random variation can become distracting when attached to motion, scale or repeated animation. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Respect user preferences and keep randomness subordinate to readability.”. 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. Rebuild the example for reduced-motion and visual comfort, predict the result, then test the reduced-motion media query. Explain both outcomes without relying on trial and error. 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. Users requesting reduced motion receive the deterministic non-animated presentation. The contrast is explained by this rule: Respect user preferences and keep randomness subordinate to readability. 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 name the evidence that matters for reduced-motion and visual comfort, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 reduced-motion and visual comfort, 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: Randomness is not cryptography · Full contents · Next: Fallbacks before enhancement →

CHAPTER 18 OF 20 · Back to contents

18. Fallbacks before enhancement

The short answer: Place a valid deterministic declaration before the experimental one. The governing rule is: The cascade can preserve a usable baseline when random() is unsupported.. 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.

Unknown or invalid values are ignored, allowing the earlier declaration to remain. 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 fallbacks before enhancement 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.

.card { rotate: 0deg; rotate: random(-2deg,2deg); }

Expected result and reasoning. Unsupported browsers keep 0deg; supporting browsers may use the later enhanced value. 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 the fallback after the enhancement overrides it everywhere. 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 declaration survives when random() is invalid?”

• Evidence to collect: the exact input, environment version, observed result and the rule for fallbacks before enhancement
• Variable to hold constant: the surrounding setup, so the comparison isolates fallbacks before enhancement.
• Variable to change: reverse the declaration order and inspect the consequence
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For fallbacks before enhancement, 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 celebration page. Transfer fallbacks before enhancement into a celebration page. Preserve the governing rule—The cascade can preserve a usable baseline when random() is unsupported.—while identifying what changes in this setting. Place a valid deterministic declaration before the experimental one. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The cascade can preserve a usable baseline when random() is unsupported.”. 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 component library. Transfer fallbacks before enhancement into a component library. Preserve the governing rule—The cascade can preserve a usable baseline when random() is unsupported.—while identifying what changes in this setting. Place a valid deterministic declaration before the experimental one. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The cascade can preserve a usable baseline when random() is unsupported.”. 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 browser-support test. Transfer fallbacks before enhancement into a browser-support test. Preserve the governing rule—The cascade can preserve a usable baseline when random() is unsupported.—while identifying what changes in this setting. Place a valid deterministic declaration before the experimental one. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The cascade can preserve a usable baseline when random() is unsupported.”. 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 visual regression fixture. Transfer fallbacks before enhancement into a visual regression fixture. Preserve the governing rule—The cascade can preserve a usable baseline when random() is unsupported.—while identifying what changes in this setting. Place a valid deterministic declaration before the experimental one. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “The cascade can preserve a usable baseline when random() is unsupported.”. 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. Rebuild the example for fallbacks before enhancement, predict the result, then reverse the declaration order and inspect the consequence. Explain both outcomes without relying on trial and error. 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. Unsupported browsers keep 0deg; supporting browsers may use the later enhanced value. The contrast is explained by this rule: The cascade can preserve a usable baseline when random() is unsupported. 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 name the evidence that matters for fallbacks before enhancement, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 fallbacks before enhancement, 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: Reduced-motion and visual comfort · Full contents · Next: Support testing is not design testing →

CHAPTER 19 OF 20 · Back to contents

19. Support testing is not design testing

The short answer: @supports answers whether the syntax is accepted, not whether the visual result is accessible or attractive. The governing rule is: Combine feature detection with range review, motion preferences and regression checks.. 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.

A browser may parse a feature correctly while a chosen range causes overlap, clipping or unreadable layouts. 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 support testing is not design testing 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.

@supports (opacity: random(0.8,1)) { .note { opacity: random(0.8,1); } }

Expected result and reasoning. The block is a support gate only; separate tests must confirm contrast and layout. 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 @supports as a quality certificate leaves design failures undetected. 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 human-visible invariant must every allowed value preserve?”

• Evidence to collect: the exact input, environment version, observed result and the rule for support testing is not design testing
• Variable to hold constant: the surrounding setup, so the comparison isolates support testing is not design testing.
• Variable to change: test min, max and representative stepped outcomes
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For support testing is not design testing, 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 design. Transfer support testing is not design testing into a reduced-motion design. Preserve the governing rule—Combine feature detection with range review, motion preferences and regression checks.—while identifying what changes in this setting. @supports answers whether the syntax is accepted, not whether the visual result is accessible or attractive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Combine feature detection with range review, motion preferences and regression checks.”. 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 classroom demo. Transfer support testing is not design testing into a classroom demo. Preserve the governing rule—Combine feature detection with range review, motion preferences and regression checks.—while identifying what changes in this setting. @supports answers whether the syntax is accepted, not whether the visual result is accessible or attractive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Combine feature detection with range review, motion preferences and regression checks.”. 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 background. Transfer support testing is not design testing into a decorative background. Preserve the governing rule—Combine feature detection with range review, motion preferences and regression checks.—while identifying what changes in this setting. @supports answers whether the syntax is accepted, not whether the visual result is accessible or attractive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Combine feature detection with range review, motion preferences and regression checks.”. 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 card gallery. Transfer support testing is not design testing into a card gallery. Preserve the governing rule—Combine feature detection with range review, motion preferences and regression checks.—while identifying what changes in this setting. @supports answers whether the syntax is accepted, not whether the visual result is accessible or attractive. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Combine feature detection with range review, motion preferences and regression checks.”. 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. Rebuild the example for support testing is not design testing, predict the result, then test min, max and representative stepped outcomes. Explain both outcomes without relying on trial and error. 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 block is a support gate only; separate tests must confirm contrast and layout. The contrast is explained by this rule: Combine feature detection with range review, motion preferences and regression checks. 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 name the evidence that matters for support testing is not design testing, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 support testing is not design testing, 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: Fallbacks before enhancement · Full contents · Next: Choosing random() for the right job →

CHAPTER 20 OF 20 · Back to contents

20. Choosing random() for the right job

The short answer: Use CSS random() for bounded, non-critical presentation variation when target support and fallbacks are acceptable. The governing rule is: Use application code, data, animation timing or fixed design tokens when their contracts better match the job.. 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 decision depends on repeatability, sharing, accessibility, security and browser support. 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 random() for the right job 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.

.avatar { --tilt: 0deg; rotate: var(--tilt); }
@supports (rotate: random(-1deg,1deg)) { .avatar { --tilt: random(element-scoped,-1deg,1deg); } }

Expected result and reasoning. This progressive enhancement remains readable and deterministic without the feature. 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 experimental randomness for essential geometry or graded output creates needless fragility. 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 user value remains if the enhancement disappears?”

• Evidence to collect: the exact input, environment version, observed result and the rule for choosing random() for the right job
• Variable to hold constant: the surrounding setup, so the comparison isolates choosing random() for the right job.
• Variable to change: remove random() and verify the page still communicates fully
• Explanation standard: name the rule, not merely the successful command or copied syntax.

For choosing random() for the right job, 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 component library. Transfer choosing random() for the right job into a component library. Preserve the governing rule—Use application code, data, animation timing or fixed design tokens when their contracts better match the job.—while identifying what changes in this setting. Use CSS random() for bounded, non-critical presentation variation when target support and fallbacks are acceptable. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use application code, data, animation timing or fixed design tokens when their contracts better match the job.”. 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 browser-support test. Transfer choosing random() for the right job into a browser-support test. Preserve the governing rule—Use application code, data, animation timing or fixed design tokens when their contracts better match the job.—while identifying what changes in this setting. Use CSS random() for bounded, non-critical presentation variation when target support and fallbacks are acceptable. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use application code, data, animation timing or fixed design tokens when their contracts better match the job.”. 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 visual regression fixture. Transfer choosing random() for the right job into a visual regression fixture. Preserve the governing rule—Use application code, data, animation timing or fixed design tokens when their contracts better match the job.—while identifying what changes in this setting. Use CSS random() for bounded, non-critical presentation variation when target support and fallbacks are acceptable. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use application code, data, animation timing or fixed design tokens when their contracts better match the job.”. 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 celebration page. Transfer choosing random() for the right job into a celebration page. Preserve the governing rule—Use application code, data, animation timing or fixed design tokens when their contracts better match the job.—while identifying what changes in this setting. Use CSS random() for bounded, non-critical presentation variation when target support and fallbacks are acceptable. Record the input, prediction, observation and version so a disagreement becomes a diagnosable case rather than a guess. Start by naming the observable evidence, then apply the chapter rule “Use application code, data, animation timing or fixed design tokens when their contracts better match the job.”. 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. Rebuild the example for choosing random() for the right job, predict the result, then remove random() and verify the page still communicates fully. Explain both outcomes without relying on trial and error. 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. This progressive enhancement remains readable and deterministic without the feature. The contrast is explained by this rule: Use application code, data, animation timing or fixed design tokens when their contracts better match the job. 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 name the evidence that matters for choosing random() for the right job, then request one controlled variation. A correct value without a causal explanation is not yet mastery. 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 random() for the right job, 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: Support testing is not design testing · Full contents · Parent guide →

Parent guide: what mastery looks like

A learner has not mastered CSS random() 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 bounded visual randomness 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 succeeds when another learner can reproduce the observation and explain the rule separating 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 with the wrong mechanism.

Route. Change the one condition the wrong explanation says matters 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. The controlled contrast exposes the misconception without turning the task into guesswork. 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 a version boundary

Scenario. Two environments 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; bind the claim to the documented environment and 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 through a causal explanation and evidence-based revision. 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 a school or home project does not.

Route. Preserve the fixture, then compare project inputs and dependencies one 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 dependency that changes the result 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 an update.

Route. Save the smallest positive case, the near miss and 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 check reports a meaningful 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 selected feature does not cover an important job or is not universally available.

Route. Name the limitation, show what evidence the feature provides and identify the safer route. Begin with a written prediction, collect the smallest sufficient evidence, and explain which observation would make you revise the conclusion.

Explained resolution. Good advice is bounded; it neither discards a useful tool nor stretches it into a guarantee. 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 appear to solve the same task.

Route. Define desired output, evaluation timing, compatibility 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 contract that matches the job 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 random() mainly a syntax topic?

No. Syntax is only the handle. Mastery means stating the contract, predicting boundary cases, collecting the right evidence, and choosing a safer or more suitable tool when the contract does not fit.

How long should one practice session be?

Ten to twenty focused minutes is enough for one rule, one worked example, one near miss and one explanation. Stop when the learner can explain the contrast; preserve the fixture for later retrieval.

Should every edge case be memorised?

No. Memorise the central rule and organise edge cases by cause: version, platform, input type, browser support, database schema or repository state. Keep the primary source beside the fixture.

What can a non-specialist parent ask?

Ask for a prediction, the rule behind it, the observation that could disprove it and one changed case. Those questions reveal understanding without requiring the parent to know the command or final value.

When is copying an example useful?

Copying establishes a trusted baseline. It becomes learning after the student predicts the result, reconstructs the example, changes one condition and explains the changed outcome.

How do we separate setup errors from concept errors?

Run a known-good minimal fixture first. If it fails, inspect version, support and transcription. If it passes but the learner predicts a controlled variation incorrectly, the misconception is conceptual.

Should practice start inside a large project?

Not initially. Begin in a disposable directory, tiny script, isolated HTML file or in-memory database. Transfer the verified rule only after the smallest case is understood.

What belongs in revision notes?

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

What if two computers disagree?

Treat the difference as evidence. Record versions, operating system or browser, exact input and relevant state. Then consult the versioned primary source before deciding that either observation is wrong.

When should the learner move on?

Move on when the learner can explain the rule, predict two contrasts, diagnose a deliberately broken case 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 editor’s draft, random values. The draft defines inclusive ranges, maximum-below-minimum behaviour, stepped outcomes, cache keys and scopes, fixed base values, evaluation caching and the explicit non-cryptographic limitation.

The worked examples were checked with the 4 September 2026 CSSWG editor’s draft plus static range and step enumeration; browser-dependent examples require target-browser verification and retain deterministic fallbacks. 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.