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

CSS :user-invalid represents a form control whose value is invalid after the user has significantly interacted with it. It is designed to avoid the common problem of painting untouched required fields as errors the moment a page loads. The exact pre-submission timing may follow host-language and browser conventions, but Selectors Level 4 requires the state to be tied to invalidity and at least to match after an unsuccessful form-submission attempt until the user interacts again or resets the form. Mastery means separating :invalid from :user-invalid, relying on HTML constraints for validity, treating CSS as presentation rather than validation, and pairing visual styling with accessible messages and testable interaction paths. This guide begins with that mechanism, then develops it through worked traces, deliberate mistakes, explained practice and transfer decisions.

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

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

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

:user-invalid can only match an element that is invalid according to the host language validation rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is writing the selector without any required, type, pattern, range or custom validity rule. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Validity comes from the control contract, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Validity comes from the control contract chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on writing the selector without any required, type, pattern, range or custom validity rule. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input id="email" type="email" required>
<style>input:user-invalid{border-color:#b3261e}</style>

Four purposeful transfer cases

Case 1: homework upload. Predict the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading club form. Contrast the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science signup. Stress-test the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA registration. Explain the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers writing the selector without any required, type, pattern, range or custom validity rule.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Validity comes from the control contract, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Validity comes from the control contract?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing writing the selector without any required, type, pattern, range or custom validity rule be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library reservation with a reset clears user-interaction state and returns the form to neutral. Include one ordinary case, one boundary and one deliberate failure caused by writing the selector without any required, type, pattern, range or custom validity rule. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Validity comes from the control contract, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

:invalid reflects current constraint validity, while :user-invalid waits for significant user interaction under the platform rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is assuming the two selectors are exact aliases. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for User interaction distinguishes it from invalid, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the User interaction distinguishes it from invalid chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on assuming the two selectors are exact aliases. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

input:invalid{outline:1px solid #999}
input:user-invalid{outline:3px solid #b3261e}

Four purposeful transfer cases

Case 1: science signup. Contrast the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA registration. Stress-test the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family contact form. Explain the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library reservation. Transfer the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers assuming the two selectors are exact aliases.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for User interaction distinguishes it from invalid, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from User interaction distinguishes it from invalid?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the two selectors are exact aliases be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid, user-invalid, focus, blur, submit and reset paths are compared. Include one ordinary case, one boundary and one deliberate failure caused by assuming the two selectors are exact aliases. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For User interaction distinguishes it from invalid, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The specification requires matching after the user attempts to submit an invalid form, subject to subsequent interaction or reset rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is testing only blur behaviour and missing the dependable submission path. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Failed submission is a required activation route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Failed submission is a required activation route chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing only blur behaviour and missing the dependable submission path. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<form><input required><button>Send</button></form>
<style>input:user-invalid{border-color:red}</style>

Four purposeful transfer cases

Case 1: family contact form. Stress-test the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library reservation. Explain the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Transfer the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Predict the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing only blur behaviour and missing the dependable submission path.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Failed submission is a required activation route, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Failed submission is a required activation route?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing only blur behaviour and missing the dependable submission path be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. Include one ordinary case, one boundary and one deliberate failure caused by testing only blur behaviour and missing the dependable submission path. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Failed submission is a required activation route, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Before submission, browsers may decide that changing a value and moving focus is significant interaction, but exact timing is not universally fixed by Selectors alone. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is promising one identical blur moment across every browser and input type. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Pre-submission timing may vary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Pre-submission timing may vary chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on promising one identical blur moment across every browser and input type. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

input:user-invalid{background:#fff4f2}

Four purposeful transfer cases

Case 1: test laboratory. Explain the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Transfer the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework upload. Predict the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading club form. Contrast the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers promising one identical blur moment across every browser and input type.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Pre-submission timing may vary, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Pre-submission timing may vary?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing promising one identical blur moment across every browser and input type be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework upload with a required file description shows feedback after an attempted submission. Include one ordinary case, one boundary and one deliberate failure caused by promising one identical blur moment across every browser and input type. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Pre-submission timing may vary, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The HTML required constraint makes a supported empty control invalid, but user-invalid presentation still depends on user interaction. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is blaming CSS when the control is optional and therefore valid while empty. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A required empty field is invalid, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the A required empty field is invalid chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on blaming CSS when the control is optional and therefore valid while empty. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input name="name" required>
<style>input:user-invalid{border-inline-start:4px solid #b3261e}</style>

Four purposeful transfer cases

Case 1: homework upload. Transfer the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading club form. Predict the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science signup. Contrast the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA registration. Stress-test the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers blaming CSS when the control is optional and therefore valid while empty.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for A required empty field is invalid, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from A required empty field is invalid?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing blaming CSS when the control is optional and therefore valid while empty be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading club form with an email field becomes user-invalid only after meaningful interaction. Include one ordinary case, one boundary and one deliberate failure caused by blaming CSS when the control is optional and therefore valid while empty. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A required empty field is invalid, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Input types such as email and url contribute built-in validity rules when the value does not satisfy their syntax. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using type=text and expecting the browser to recognise an email format automatically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Type mismatch can drive the state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Type mismatch can drive the state chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using type=text and expecting the browser to recognise an email format automatically. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input type="email" required value="not-an-email">

Four purposeful transfer cases

Case 1: science signup. Predict the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA registration. Contrast the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family contact form. Stress-test the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library reservation. Explain the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using type=text and expecting the browser to recognise an email format automatically.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Type mismatch can drive the state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Type mismatch can drive the state?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using type=text and expecting the browser to recognise an email format automatically be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science signup with a number outside its min–max range receives a clear error state. Include one ordinary case, one boundary and one deliberate failure caused by using type=text and expecting the browser to recognise an email format automatically. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Type mismatch can drive the state, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Number and date-like controls can be invalid because values fall below min, above max or violate step. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is showing one generic error message that says required when the actual value is out of range. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Range constraints are distinct evidence, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Range constraints are distinct evidence chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on showing one generic error message that says required when the actual value is out of range. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input type="number" min="0" max="10" value="11">

Four purposeful transfer cases

Case 1: family contact form. Contrast the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library reservation. Stress-test the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Explain the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Transfer the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers showing one generic error message that says required when the actual value is out of range.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Range constraints are distinct evidence, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Range constraints are distinct evidence?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing showing one generic error message that says required when the actual value is out of range be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA registration with a required selection and consent checkbox are tested by keyboard. Include one ordinary case, one boundary and one deliberate failure caused by showing one generic error message that says required when the actual value is out of range. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Range constraints are distinct evidence, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

The pattern attribute constrains appropriate text-like values, while an empty value is not made invalid by pattern alone unless required also applies. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is expecting pattern to make an optional empty input fail. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Pattern mismatch applies to non-empty values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Pattern mismatch applies to non-empty values chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on expecting pattern to make an optional empty input fail. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input pattern="[A-Z]{3}" required>

Four purposeful transfer cases

Case 1: test laboratory. Stress-test the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Explain the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework upload. Transfer the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading club form. Predict the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers expecting pattern to make an optional empty input fail.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Pattern mismatch applies to non-empty values, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Pattern mismatch applies to non-empty values?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing expecting pattern to make an optional empty input fail be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family contact form with a telephone pattern uses text, border and message cues together. Include one ordinary case, one boundary and one deliberate failure caused by expecting pattern to make an optional empty input fail. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Pattern mismatch applies to non-empty values, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

JavaScript setCustomValidity can make a control invalid, allowing the user-invalid selector to present that state after interaction. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding a red class while leaving the browser validity model unchanged. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Custom validity integrates with the same model, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Custom validity integrates with the same model chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding a red class while leaving the browser validity model unchanged. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const input=document.querySelector('input');
input.setCustomValidity('Code already used');

Four purposeful transfer cases

Case 1: homework upload. Explain the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading club form. Transfer the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science signup. Predict the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA registration. Contrast the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding a red class while leaving the browser validity model unchanged.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Custom validity integrates with the same model, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Custom validity integrates with the same model?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding a red class while leaving the browser validity model unchanged be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library reservation with a reset clears user-interaction state and returns the form to neutral. Include one ordinary case, one boundary and one deliberate failure caused by adding a red class while leaving the browser validity model unchanged. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Custom validity integrates with the same model, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

:user-invalid styles a state; it does not sanitize data, protect a server or decide business rules. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating a green border as proof that submitted data is safe. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for CSS does not replace validation logic, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the CSS does not replace validation logic chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating a green border as proof that submitted data is safe. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

input:user-invalid{border-color:#b3261e}

Four purposeful transfer cases

Case 1: science signup. Transfer the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA registration. Predict the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family contact form. Contrast the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library reservation. Stress-test the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating a green border as proof that submitted data is safe.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for CSS does not replace validation logic, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from CSS does not replace validation logic?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating a green border as proof that submitted data is safe be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid, user-invalid, focus, blur, submit and reset paths are compared. Include one ordinary case, one boundary and one deliberate failure caused by treating a green border as proof that submitted data is safe. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For CSS does not replace validation logic, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Accessible error treatment should combine colour with text, shape, iconography or another cue and maintain readable contrast. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using only a subtle red tint that some users cannot perceive. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Do not rely on colour alone, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Do not rely on colour alone chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using only a subtle red tint that some users cannot perceive. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

input:user-invalid{border:3px solid #8b1e1e}
input:user-invalid + .error{font-weight:700}

Four purposeful transfer cases

Case 1: family contact form. Predict the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library reservation. Contrast the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Stress-test the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Explain the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using only a subtle red tint that some users cannot perceive.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Do not rely on colour alone, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Do not rely on colour alone?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using only a subtle red tint that some users cannot perceive be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. Include one ordinary case, one boundary and one deliberate failure caused by using only a subtle red tint that some users cannot perceive. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Do not rely on colour alone, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Generated or shown error text should be programmatically associated with the input, commonly through aria-describedby, and kept accurate. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is displaying text nearby with no relationship available to assistive technology. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A visible message still needs semantics, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the A visible message still needs semantics chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on displaying text nearby with no relationship available to assistive technology. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

<input id="age" aria-describedby="age-error" min="12" type="number">
<p id="age-error">Enter 12 or more.</p>

Four purposeful transfer cases

Case 1: test laboratory. Contrast the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Stress-test the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework upload. Explain the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading club form. Transfer the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers displaying text nearby with no relationship available to assistive technology.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for A visible message still needs semantics, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from A visible message still needs semantics?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing displaying text nearby with no relationship available to assistive technology be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework upload with a required file description shows feedback after an attempted submission. Include one ordinary case, one boundary and one deliberate failure caused by displaying text nearby with no relationship available to assistive technology. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A visible message still needs semantics, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

:user-invalid follows native validity and interaction state; aria-invalid communicates an accessibility state but does not itself make the CSS pseudo-class match. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is setting aria-invalid=true and expecting :user-invalid to activate automatically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for aria-invalid is not the same selector, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the aria-invalid is not the same selector chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on setting aria-invalid=true and expecting :user-invalid to activate automatically. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

[aria-invalid="true"]{border-color:#b3261e}
input:user-invalid{border-color:#b3261e}

Four purposeful transfer cases

Case 1: homework upload. Stress-test the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading club form. Explain the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science signup. Transfer the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA registration. Predict the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers setting aria-invalid=true and expecting :user-invalid to activate automatically.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for aria-invalid is not the same selector, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from aria-invalid is not the same selector?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing setting aria-invalid=true and expecting :user-invalid to activate automatically be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny reading club form with an email field becomes user-invalid only after meaningful interaction. Include one ordinary case, one boundary and one deliberate failure caused by setting aria-invalid=true and expecting :user-invalid to activate automatically. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For aria-invalid is not the same selector, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Error styling should not erase a clear :focus-visible indicator for keyboard users. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using outline:none in the error rule and losing keyboard location. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Focus styling must remain visible, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Focus styling must remain visible chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using outline:none in the error rule and losing keyboard location. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

input:user-invalid{border-color:#b3261e}
input:focus-visible{outline:3px solid #145da0;outline-offset:2px}

Four purposeful transfer cases

Case 1: science signup. Explain the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA registration. Transfer the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family contact form. Predict the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library reservation. Contrast the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using outline:none in the error rule and losing keyboard location.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Focus styling must remain visible, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Focus styling must remain visible?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using outline:none in the error rule and losing keyboard location be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science signup with a number outside its min–max range receives a clear error state. Include one ordinary case, one boundary and one deliberate failure caused by using outline:none in the error rule and losing keyboard location. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Focus styling must remain visible, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

:user-invalid contributes pseudo-class specificity, so source order and surrounding selectors determine which declaration wins. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding repeated selectors or !important without calculating the competing rules. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Specificity follows ordinary pseudo-class rules, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Specificity follows ordinary pseudo-class rules chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding repeated selectors or !important without calculating the competing rules. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.field:user-invalid{border-color:#b3261e}
.checkout .field{border-color:#777}

Four purposeful transfer cases

Case 1: family contact form. Transfer the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library reservation. Predict the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Contrast the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Stress-test the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding repeated selectors or !important without calculating the competing rules.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Specificity follows ordinary pseudo-class rules, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Specificity follows ordinary pseudo-class rules?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding repeated selectors or !important without calculating the competing rules be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA registration with a required selection and consent checkbox are tested by keyboard. Include one ordinary case, one boundary and one deliberate failure caused by adding repeated selectors or !important without calculating the competing rules. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Specificity follows ordinary pseudo-class rules, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

:is(:user-invalid,[aria-invalid=”true”]) can apply a common visual treatment while preserving distinct state management. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is grouping states and then assuming they become semantically interchangeable. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Grouping with is can share state styling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Grouping with is can share state styling chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on grouping states and then assuming they become semantically interchangeable. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.field:is(:user-invalid,[aria-invalid="true"]){border-inline-start:4px solid #b3261e}

Four purposeful transfer cases

Case 1: test laboratory. Predict the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Contrast the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework upload. Stress-test the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading club form. Explain the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers grouping states and then assuming they become semantically interchangeable.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Grouping with is can share state styling, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Grouping with is can share state styling?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing grouping states and then assuming they become semantically interchangeable be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family contact form with a telephone pattern uses text, border and message cues together. Include one ordinary case, one boundary and one deliberate failure caused by grouping states and then assuming they become semantically interchangeable. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Grouping with is can share state styling, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

@supports selector(:user-invalid) can gate the interaction-aware rule while a simpler baseline remains available. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is hiding all error treatment in a browser that cannot parse the selector. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for A support query can protect enhancement, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the A support query can protect enhancement chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on hiding all error treatment in a browser that cannot parse the selector. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.field:invalid{border-color:#8b1e1e}
@supports selector(:user-invalid){.field:invalid{border-color:#777}.field:user-invalid{border-color:#8b1e1e}}

Four purposeful transfer cases

Case 1: homework upload. Contrast the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: reading club form. Stress-test the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: science signup. Explain the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: CCA registration. Transfer the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers hiding all error treatment in a browser that cannot parse the selector.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for A support query can protect enhancement, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from A support query can protect enhancement?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing hiding all error treatment in a browser that cannot parse the selector be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library reservation with a reset clears user-interaction state and returns the form to neutral. Include one ordinary case, one boundary and one deliberate failure caused by hiding all error treatment in a browser that cannot parse the selector. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A support query can protect enhancement, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Resetting the form restores default values and clears the submission-driven user-interaction state under the HTML behaviour. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is leaving stale custom error messages or application classes after a reset. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Reset returns the form toward neutral interaction state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Reset returns the form toward neutral interaction state chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on leaving stale custom error messages or application classes after a reset. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

form.reset();
input.setCustomValidity('');

Four purposeful transfer cases

Case 1: science signup. Stress-test the rule using a number outside its min–max range receives a clear error state. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: CCA registration. Explain the rule using a required selection and consent checkbox are tested by keyboard. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: family contact form. Transfer the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: library reservation. Predict the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers leaving stale custom error messages or application classes after a reset.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Reset returns the form toward neutral interaction state, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Reset returns the form toward neutral interaction state?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing leaving stale custom error messages or application classes after a reset be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny test laboratory with invalid, user-invalid, focus, blur, submit and reset paths are compared. Include one ordinary case, one boundary and one deliberate failure caused by leaving stale custom error messages or application classes after a reset. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Reset returns the form toward neutral interaction state, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

A reliable test covers untouched load, invalid edit, focus movement, failed submit, correction, keyboard operation and reset in target browsers. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is taking a screenshot of one red field as proof that the complete flow works. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Testing needs an interaction matrix, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Testing needs an interaction matrix chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on taking a screenshot of one red field as proof that the complete flow works. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

// test: load -> focus -> type invalid -> blur -> submit -> correct -> reset

Four purposeful transfer cases

Case 1: family contact form. Explain the rule using a telephone pattern uses text, border and message cues together. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: library reservation. Transfer the rule using a reset clears user-interaction state and returns the form to neutral. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: test laboratory. Predict the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: design decision. Contrast the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers taking a screenshot of one red field as proof that the complete flow works.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Testing needs an interaction matrix, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Testing needs an interaction matrix?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing taking a screenshot of one red field as proof that the complete flow works be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design decision with :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. Include one ordinary case, one boundary and one deliberate failure caused by taking a screenshot of one red field as proof that the complete flow works. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Testing needs an interaction matrix, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

Use :user-invalid when HTML validity plus user interaction should control feedback; use :invalid for immediate state, aria-invalid or classes for application-managed rules, and JavaScript when timing or messages require explicit control. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding the selector to every input without deciding who owns validity and messages. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. State the contract for Choose user-invalid for delayed native error presentation, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.

For the Choose user-invalid for delayed native error presentation chapter on CSS :user-invalid, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding the selector to every input without deciding who owns validity and messages. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.field:user-invalid + .error{display:block}

Four purposeful transfer cases

Case 1: test laboratory. Transfer the rule using invalid, user-invalid, focus, blur, submit and reset paths are compared. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: design decision. Predict the rule using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework upload. Contrast the rule using a required file description shows feedback after an attempted submission. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: reading club form. Stress-test the rule using an email field becomes user-invalid only after meaningful interaction. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding the selector to every input without deciding who owns validity and messages.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “State the contract for Choose user-invalid for delayed native error presentation, predict one ordinary case and one boundary, run the smallest disposable test, then explain the earliest difference between prediction and evidence.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS :user-invalid syntax. For this chapter, useful prompts are: “What did you expect from Choose user-invalid for delayed native error presentation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding the selector to every input without deciding who owns validity and messages be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework upload with a required file description shows feedback after an attempted submission. Include one ordinary case, one boundary and one deliberate failure caused by adding the selector to every input without deciding who owns validity and messages. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Choose user-invalid for delayed native error presentation, separate the documented CSS :user-invalid mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

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

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

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

1. homework upload: model, boundary and recovery

Create a small homework upload using a required file description shows feedback after an attempted submission. Combine “Validity comes from the control contract” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. reading club form: model, boundary and recovery

Create a small reading club form using an email field becomes user-invalid only after meaningful interaction. Combine “Pre-submission timing may vary” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. science signup: model, boundary and recovery

Create a small science signup using a number outside its min–max range receives a clear error state. Combine “Range constraints are distinct evidence” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. CCA registration: model, boundary and recovery

Create a small CCA registration using a required selection and consent checkbox are tested by keyboard. Combine “CSS does not replace validation logic” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. family contact form: model, boundary and recovery

Create a small family contact form using a telephone pattern uses text, border and message cues together. Combine “aria-invalid is not the same selector” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. library reservation: model, boundary and recovery

Create a small library reservation using a reset clears user-interaction state and returns the form to neutral. Combine “Grouping with is can share state styling” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. test laboratory: model, boundary and recovery

Create a small test laboratory using invalid, user-invalid, focus, blur, submit and reset paths are compared. Combine “Testing needs an interaction matrix” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. design decision: model, boundary and recovery

Create a small design decision using :user-invalid is compared with :invalid, classes, aria-invalid and JavaScript validation. Combine “User interaction distinguishes it from invalid” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

Frequently asked questions

How long should a practice session be?

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

Should every option or function be memorised?

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

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

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

Is the shortest solution the best?

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

When should official documentation be used?

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

How can a parent help without technical expertise?

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

How do we test transfer?

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

What should be saved after practice?

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

Can these exercises replace backups?

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

What counts as mastery?

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

Official and supporting references

• Primary technical documentation for CSS :user-invalid
• eduKatePunggol: How Studying Works

Return to contents