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 font-variant-alternates selects font-specific alternate glyphs—such as stylistic alternates, stylesets, character variants, swashes, ornaments and annotation forms—without changing the underlying text. The readable names used in the property are mapped to numeric font features through @font-feature-values. Mastery therefore requires separating characters from glyphs, CSS parsing from font support, and decoration from readable content. 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.

font-variant-alternates changes which glyph a font uses for existing characters; it does not rewrite the document text. 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 reading a decorative shape as a different character or storing ornamented Unicode lookalikes. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Copy the text, inspect the DOM string and compare it with the painted glyph.

For the Characters and glyphs are different layers chapter on CSS font-variant-alternates, 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 reading a decorative shape as a different character or storing ornamented Unicode lookalikes. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.heading { font-variant-alternates: historical-forms; }

Four purposeful transfer cases

Case 1: project heading. Predict the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Contrast the rule using ornamental initials, ordinary body text and a readable print version. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Stress-test the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science label. Explain the rule using stable characters, a character variant and copy-paste verification. 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 reading a decorative shape as a different character or storing ornamented Unicode lookalikes.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Copy the text, inspect the DOM string and compare it with the painted glyph.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Characters and glyphs are different layers?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading a decorative shape as a different character or storing ornamented Unicode lookalikes be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family invitation with a swash-capable font, conservative spacing and fallback testing. Include one ordinary case, one boundary and one deliberate failure caused by reading a decorative shape as a different character or storing ornamented Unicode lookalikes. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Characters and glyphs are different layers, separate the documented CSS font-variant-alternates 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

normal disables the alternate-feature selections controlled by this property. 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 normal selects a browser-preferred decorative alternate. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Reset one element to normal and compare computed style and rendering with the styled neighbour.

For the The initial value is normal chapter on CSS font-variant-alternates, 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 normal selects a browser-preferred decorative alternate. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.plain { font-variant-alternates: normal; }

Four purposeful transfer cases

Case 1: CCA badge. Contrast the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science label. Stress-test the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Explain the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family invitation. Transfer the rule using a swash-capable font, conservative spacing and fallback testing. 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 normal selects a browser-preferred decorative alternate.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Reset one element to normal and compare computed style and rendering with the styled neighbour.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from The initial value is normal?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming normal selects a browser-preferred decorative alternate be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny web article with inherited typography, scoped overrides and browser inspection. Include one ordinary case, one boundary and one deliberate failure caused by assuming normal selects a browser-preferred decorative alternate. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The initial value is normal, separate the documented CSS font-variant-alternates 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 descendant normally receives its parent’s computed font-variant-alternates value. 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 placing the rule on a large container and unintentionally decorating labels or long paragraphs. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect computed styles down the tree and reset the smallest subtree that needs ordinary forms.

For the The property is inherited chapter on CSS font-variant-alternates, 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 placing the rule on a large container and unintentionally decorating labels or long paragraphs. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.poster { font-variant-alternates: historical-forms; }
.poster .details { font-variant-alternates: normal; }

Four purposeful transfer cases

Case 1: revision card. Stress-test the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family invitation. Explain the rule using a swash-capable font, conservative spacing and fallback testing. 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: web article. Transfer the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Predict the rule using feature names, font files, screenshots and regression cases. 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 placing the rule on a large container and unintentionally decorating labels or long paragraphs.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect computed styles down the tree and reset the smallest subtree that needs ordinary forms.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from The property is inherited?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing placing the rule on a large container and unintentionally decorating labels or long paragraphs be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design-system specimen with feature names, font files, screenshots and regression cases. Include one ordinary case, one boundary and one deliberate failure caused by placing the rule on a large container and unintentionally decorating labels or long paragraphs. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The property is inherited, separate the documented CSS font-variant-alternates 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 historical-forms keyword requests the OpenType historical forms feature when the selected font supports it. 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 historical lettering as universally available or automatically more authentic. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use a documented test string, compare fonts and retain a readable normal control.

For the historical-forms has a direct keyword chapter on CSS font-variant-alternates, 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 historical lettering as universally available or automatically more authentic. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.history-sample { font-variant-alternates: historical-forms; }

Four purposeful transfer cases

Case 1: web article. Explain the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Transfer the rule using feature names, font files, screenshots and regression cases. 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: project heading. Predict the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Contrast the rule using ornamental initials, ordinary body text and a readable print version. 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 historical lettering as universally available or automatically more authentic.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use a documented test string, compare fonts and retain a readable normal control.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from historical-forms has a direct keyword?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating historical lettering as universally available or automatically more authentic be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny project heading with a display typeface, a named stylistic alternate and a plain fallback. Include one ordinary case, one boundary and one deliberate failure caused by treating historical lettering as universally available or automatically more authentic. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For historical-forms has a direct keyword, separate the documented CSS font-variant-alternates 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

stylistic(name) refers to a font-specific stylistic alternate name defined with @font-feature-values. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is putting a numeric OpenType parameter directly inside stylistic(). It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Define the readable name for the exact font family, then use that identifier in the property.

For the stylistic() selects a named alternate chapter on CSS font-variant-alternates, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on putting a numeric OpenType parameter directly inside stylistic(). Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Demo { @stylistic { friendly: 1; } }
.title { font-family: Demo; font-variant-alternates: stylistic(friendly); }

Four purposeful transfer cases

Case 1: project heading. Transfer the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Predict the rule using ornamental initials, ordinary body text and a readable print version. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Contrast the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science label. Stress-test the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers putting a numeric OpenType parameter directly inside stylistic().
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Define the readable name for the exact font family, then use that identifier in the property.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from stylistic() selects a named alternate?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing putting a numeric OpenType parameter directly inside stylistic() be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library poster with ornamental initials, ordinary body text and a readable print version. Include one ordinary case, one boundary and one deliberate failure caused by putting a numeric OpenType parameter directly inside stylistic(). Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For stylistic() selects a named alternate, separate the documented CSS font-variant-alternates 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

styleset() selects one or more named stylistic sets whose numeric meanings come from the active font mapping. 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 same styleset number means the same design across unrelated fonts. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep mappings beside each family and test every named set against its font documentation.

For the styleset() can combine named sets chapter on CSS font-variant-alternates, 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 same styleset number means the same design across unrelated fonts. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Demo { @styleset { school: 1; rounded: 3; } }
.logo { font-variant-alternates: styleset(school, rounded); }

Four purposeful transfer cases

Case 1: CCA badge. Predict the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science label. Contrast the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Stress-test the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family invitation. Explain the rule using a swash-capable font, conservative spacing and fallback testing. 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 same styleset number means the same design across unrelated fonts.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep mappings beside each family and test every named set against its font documentation.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from styleset() can combine named sets?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the same styleset number means the same design across unrelated fonts be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA badge with short team lettering, a controlled styleset and accessible text. Include one ordinary case, one boundary and one deliberate failure caused by assuming the same styleset number means the same design across unrelated fonts. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For styleset() can combine named sets, separate the documented CSS font-variant-alternates 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

character-variant() chooses named character-variant features and may include an alternate index through the mapping rule. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using it as a text-replacement mechanism for spelling or symbols. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. List the affected characters from the font specimen and verify copied text remains original.

For the character-variant() targets variant groups chapter on CSS font-variant-alternates, 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 it as a text-replacement mechanism for spelling or symbols. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Demo { @character-variant { open-four: 4 1; } }
.data { font-variant-alternates: character-variant(open-four); }

Four purposeful transfer cases

Case 1: revision card. Contrast the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family invitation. Stress-test the rule using a swash-capable font, conservative spacing and fallback testing. 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: web article. Explain the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Transfer the rule using feature names, font files, screenshots and regression cases. 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 it as a text-replacement mechanism for spelling or symbols.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “List the affected characters from the font specimen and verify copied text remains original.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from character-variant() targets variant groups?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using it as a text-replacement mechanism for spelling or symbols be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science label with stable characters, a character variant and copy-paste verification. Include one ordinary case, one boundary and one deliberate failure caused by using it as a text-replacement mechanism for spelling or symbols. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For character-variant() targets variant groups, separate the documented CSS font-variant-alternates 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

swash(name) chooses a named swash mapping for a font that provides suitable alternate glyphs. 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 applying swashes to dense paragraphs, form fields or identifiers where shapes impede reading. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Restrict the effect to short display text and test collisions at narrow widths.

For the swash() is font-specific display styling chapter on CSS font-variant-alternates, 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 applying swashes to dense paragraphs, form fields or identifiers where shapes impede reading. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Script { @swash { gentle: 1; } }
.invitation { font-family: Script; font-variant-alternates: swash(gentle); }

Four purposeful transfer cases

Case 1: web article. Stress-test the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Explain the rule using feature names, font files, screenshots and regression cases. 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: project heading. Transfer the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Predict the rule using ornamental initials, ordinary body text and a readable print version. 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 applying swashes to dense paragraphs, form fields or identifiers where shapes impede reading.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Restrict the effect to short display text and test collisions at narrow widths.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from swash() is font-specific display styling?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing applying swashes to dense paragraphs, form fields or identifiers where shapes impede reading be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision card with one decorative heading and unaffected explanation text. Include one ordinary case, one boundary and one deliberate failure caused by applying swashes to dense paragraphs, form fields or identifiers where shapes impede reading. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For swash() is font-specific display styling, separate the documented CSS font-variant-alternates 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

ornaments(name) requests a named ornament selection from the chosen font family. 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 an ornament glyph as the only accessible label or instruction. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep semantic text in the DOM and mark purely decorative output so it does not replace meaning.

For the ornaments() uses a font ornament feature chapter on CSS font-variant-alternates, 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 an ornament glyph as the only accessible label or instruction. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Display { @ornaments { leaf: 2; } }
.divider { font-variant-alternates: ornaments(leaf); }

Four purposeful transfer cases

Case 1: project heading. Explain the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Transfer the rule using ornamental initials, ordinary body text and a readable print version. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Predict the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science label. Contrast the rule using stable characters, a character variant and copy-paste verification. 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 an ornament glyph as the only accessible label or instruction.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep semantic text in the DOM and mark purely decorative output so it does not replace meaning.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from ornaments() uses a font ornament feature?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using an ornament glyph as the only accessible label or instruction be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family invitation with a swash-capable font, conservative spacing and fallback testing. Include one ordinary case, one boundary and one deliberate failure caused by using an ornament glyph as the only accessible label or instruction. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For ornaments() uses a font ornament feature, separate the documented CSS font-variant-alternates 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

annotation(name) addresses a font’s alternate annotation forms through a named mapping. 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 feature creates semantic annotations or tooltips. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Provide actual explanatory text in HTML and treat the glyph choice only as typography.

For the annotation() selects alternate annotation forms chapter on CSS font-variant-alternates, 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 feature creates semantic annotations or tooltips. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values Notes { @annotation { circled: 1; } }
.marker { font-variant-alternates: annotation(circled); }

Four purposeful transfer cases

Case 1: CCA badge. Transfer the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science label. Predict the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Contrast the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family invitation. Stress-test the rule using a swash-capable font, conservative spacing and fallback testing. 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 feature creates semantic annotations or tooltips.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Provide actual explanatory text in HTML and treat the glyph choice only as typography.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from annotation() selects alternate annotation forms?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the feature creates semantic annotations or tooltips be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny web article with inherited typography, scoped overrides and browser inspection. Include one ordinary case, one boundary and one deliberate failure caused by assuming the feature creates semantic annotations or tooltips. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For annotation() selects alternate annotation forms, separate the documented CSS font-variant-alternates 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

Mappings are associated with named font families because numeric alternate indices are font-specific. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is declaring one global name and expecting every fallback font to interpret it identically. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Review each family block and record its source font version and feature specimen.

For the @font-feature-values binds names to families chapter on CSS font-variant-alternates, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on declaring one global name and expecting every fallback font to interpret it identically. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@font-feature-values 'Study Sans' { @styleset { clear-l: 2; } }

Four purposeful transfer cases

Case 1: revision card. Predict the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family invitation. Contrast the rule using a swash-capable font, conservative spacing and fallback testing. 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: web article. Stress-test the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Explain the rule using feature names, font files, screenshots and regression cases. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers declaring one global name and expecting every fallback font to interpret it identically.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Review each family block and record its source font version and feature specimen.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from @font-feature-values binds names to families?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing declaring one global name and expecting every fallback font to interpret it identically be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design-system specimen with feature names, font files, screenshots and regression cases. Include one ordinary case, one boundary and one deliberate failure caused by declaring one global name and expecting every fallback font to interpret it identically. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For @font-feature-values binds names to families, separate the documented CSS font-variant-alternates 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

When a name lacks a relevant mapping for the active family, it is ignored for glyph selection rather than inventing a feature. 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 mistaking a valid parsed declaration with an undefined name for proof that the effect works. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check the mapping rule, active computed font and visible supporting glyphs separately.

For the Undefined names do not choose glyphs chapter on CSS font-variant-alternates, 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 mistaking a valid parsed declaration with an undefined name for proof that the effect works. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.sample { font-variant-alternates: swash(not-defined); }

Four purposeful transfer cases

Case 1: web article. Contrast the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Stress-test the rule using feature names, font files, screenshots and regression cases. 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: project heading. Explain the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Transfer the rule using ornamental initials, ordinary body text and a readable print version. 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 mistaking a valid parsed declaration with an undefined name for proof that the effect works.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Check the mapping rule, active computed font and visible supporting glyphs separately.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Undefined names do not choose glyphs?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mistaking a valid parsed declaration with an undefined name for proof that the effect works be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny project heading with a display typeface, a named stylistic alternate and a plain fallback. Include one ordinary case, one boundary and one deliberate failure caused by mistaking a valid parsed declaration with an undefined name for proof that the effect works. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Undefined names do not choose glyphs, separate the documented CSS font-variant-alternates 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

If font fallback chooses another family, a mapping tied to the intended family may no longer apply. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is debugging only the property while the actual glyph comes from a fallback font. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Use developer font inspection per character and test missing-glyph and loading-failure cases.

For the Fallbacks can remove the visible effect chapter on CSS font-variant-alternates, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on debugging only the property while the actual glyph comes from a fallback font. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.sample { font-family: Demo, sans-serif; font-variant-alternates: stylistic(friendly); }

Four purposeful transfer cases

Case 1: project heading. Stress-test the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Explain the rule using ornamental initials, ordinary body text and a readable print version. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Transfer the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science label. Predict the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers debugging only the property while the actual glyph comes from a fallback font.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Use developer font inspection per character and test missing-glyph and loading-failure cases.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Fallbacks can remove the visible effect?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing debugging only the property while the actual glyph comes from a fallback font be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library poster with ornamental initials, ordinary body text and a readable print version. Include one ordinary case, one boundary and one deliberate failure caused by debugging only the property while the actual glyph comes from a fallback font. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Fallbacks can remove the visible effect, separate the documented CSS font-variant-alternates 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

Font-specific feature-value names are not defined for generic families such as serif or sans-serif. 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 attaching a numeric design promise to a generic family whose actual font varies by platform. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Name and load the intended font, then provide a normal fallback experience.

For the Generic families do not own these mappings chapter on CSS font-variant-alternates, 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 attaching a numeric design promise to a generic family whose actual font varies by platform. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.generic { font-family: serif; font-variant-alternates: normal; }

Four purposeful transfer cases

Case 1: CCA badge. Explain the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science label. Transfer the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Predict the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family invitation. Contrast the rule using a swash-capable font, conservative spacing and fallback testing. 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 attaching a numeric design promise to a generic family whose actual font varies by platform.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Name and load the intended font, then provide a normal fallback experience.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Generic families do not own these mappings?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing attaching a numeric design promise to a generic family whose actual font varies by platform be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA badge with short team lettering, a controlled styleset and accessible text. Include one ordinary case, one boundary and one deliberate failure caused by attaching a numeric design promise to a generic family whose actual font varies by platform. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Generic families do not own these mappings, separate the documented CSS font-variant-alternates 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 grammar permits compatible alternate functions and keywords to be requested together, subject to font support and feature 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 stacking features without checking whether one overrides or visually conflicts with another. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Add one feature at a time, record the glyph change and test the final combination.

For the Multiple alternate categories may combine chapter on CSS font-variant-alternates, 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 stacking features without checking whether one overrides or visually conflicts with another. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.display { font-variant-alternates: historical-forms styleset(school) swash(gentle); }

Four purposeful transfer cases

Case 1: revision card. Transfer the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family invitation. Predict the rule using a swash-capable font, conservative spacing and fallback testing. 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: web article. Contrast the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Stress-test the rule using feature names, font files, screenshots and regression cases. 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 stacking features without checking whether one overrides or visually conflicts with another.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Add one feature at a time, record the glyph change and test the final combination.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Multiple alternate categories may combine?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing stacking features without checking whether one overrides or visually conflicts with another be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science label with stable characters, a character variant and copy-paste verification. Include one ordinary case, one boundary and one deliberate failure caused by stacking features without checking whether one overrides or visually conflicts with another. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Multiple alternate categories may combine, separate the documented CSS font-variant-alternates 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

Using the font shorthand can reset font-variant subproperties, including alternate selection, according to shorthand 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 setting alternates first and later erasing them with an unrelated-looking font declaration. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Inspect cascade order and computed values after every shorthand in the rule set.

For the The font shorthand can reset subproperties chapter on CSS font-variant-alternates, 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 alternates first and later erasing them with an unrelated-looking font declaration. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.title { font-variant-alternates: styleset(school); font: 700 2rem Demo; }

Four purposeful transfer cases

Case 1: web article. Predict the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Contrast the rule using feature names, font files, screenshots and regression cases. 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: project heading. Stress-test the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Explain the rule using ornamental initials, ordinary body text and a readable print version. 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 alternates first and later erasing them with an unrelated-looking font declaration.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Inspect cascade order and computed values after every shorthand in the rule set.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from The font shorthand can reset subproperties?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing setting alternates first and later erasing them with an unrelated-looking font declaration be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision card with one decorative heading and unaffected explanation text. Include one ordinary case, one boundary and one deliberate failure caused by setting alternates first and later erasing them with an unrelated-looking font declaration. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The font shorthand can reset subproperties, separate the documented CSS font-variant-alternates 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

font-feature-settings addresses OpenType tags directly, while font-variant-alternates provides named, property-level controls where 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 mixing both layers without deciding which declaration should win for the same feature. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Prefer the semantic property, reserve raw tags for unsupported cases and inspect the cascade.

For the font-feature-settings is a lower-level escape hatch chapter on CSS font-variant-alternates, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on mixing both layers without deciding which declaration should win for the same feature. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.raw { font-feature-settings: 'ss01' 1; }
.named { font-variant-alternates: styleset(school); }

Four purposeful transfer cases

Case 1: project heading. Contrast the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Stress-test the rule using ornamental initials, ordinary body text and a readable print version. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: CCA badge. Explain the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: science label. Transfer the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers mixing both layers without deciding which declaration should win for the same feature.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Prefer the semantic property, reserve raw tags for unsupported cases and inspect the cascade.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from font-feature-settings is a lower-level escape hatch?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing mixing both layers without deciding which declaration should win for the same feature be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny family invitation with a swash-capable font, conservative spacing and fallback testing. Include one ordinary case, one boundary and one deliberate failure caused by mixing both layers without deciding which declaration should win for the same feature. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For font-feature-settings is a lower-level escape hatch, separate the documented CSS font-variant-alternates 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 browser must implement the CSS syntax and the selected font must contain the requested feature and mapped index. 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 calling a property unsupported when the real issue is a font file with no alternate. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Run CSS.supports, inspect the loaded font and compare a known feature specimen.

For the Support has two independent gates chapter on CSS font-variant-alternates, 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 calling a property unsupported when the real issue is a font file with no alternate. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.log(CSS.supports('font-variant-alternates','historical-forms'));

Four purposeful transfer cases

Case 1: CCA badge. Stress-test the rule using short team lettering, a controlled styleset and accessible text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: science label. Explain the rule using stable characters, a character variant and copy-paste verification. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: revision card. Transfer the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 4: family invitation. Predict the rule using a swash-capable font, conservative spacing and fallback testing. 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 calling a property unsupported when the real issue is a font file with no alternate.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Run CSS.supports, inspect the loaded font and compare a known feature specimen.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Support has two independent gates?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing calling a property unsupported when the real issue is a font file with no alternate be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny web article with inherited typography, scoped overrides and browser inspection. Include one ordinary case, one boundary and one deliberate failure caused by calling a property unsupported when the real issue is a font file with no alternate. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Support has two independent gates, separate the documented CSS font-variant-alternates 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

Alternate glyph tests are meaningful only when the font file, feature mapping, browser conditions and specimen text are controlled. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is using a screenshot of arbitrary prose that contains no affected character. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Choose minimal diagnostic strings and store normal and alternate references together.

For the Visual regression needs stable fonts and strings chapter on CSS font-variant-alternates, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on using a screenshot of arbitrary prose that contains no affected character. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

const specimen='A4Q ampersand';
console.log(specimen);

Four purposeful transfer cases

Case 1: revision card. Explain the rule using one decorative heading and unaffected explanation text. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 2: family invitation. Transfer the rule using a swash-capable font, conservative spacing and fallback testing. 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: web article. Predict the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Contrast the rule using feature names, font files, screenshots and regression cases. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers using a screenshot of arbitrary prose that contains no affected character.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Choose minimal diagnostic strings and store normal and alternate references together.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Visual regression needs stable fonts and strings?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using a screenshot of arbitrary prose that contains no affected character be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny design-system specimen with feature names, font files, screenshots and regression cases. Include one ordinary case, one boundary and one deliberate failure caused by using a screenshot of arbitrary prose that contains no affected character. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Visual regression needs stable fonts and strings, separate the documented CSS font-variant-alternates 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

Alternate glyphs should enrich presentation while labels, reading order, copy-paste text and spoken output remain understandable. 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 ornate forms where students must distinguish similar characters or enter exact codes. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test zoom, contrast, copy-paste, screen-reader text and a plain-font fallback before release.

For the Accessible design keeps meaning independent chapter on CSS font-variant-alternates, 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 ornate forms where students must distinguish similar characters or enter exact codes. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.code, input, button { font-variant-alternates: normal; }

Four purposeful transfer cases

Case 1: web article. Transfer the rule using inherited typography, scoped overrides and browser inspection. 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-system specimen. Predict the rule using feature names, font files, screenshots and regression cases. 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: project heading. Contrast the rule using a display typeface, a named stylistic alternate and a plain fallback. 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 poster. Stress-test the rule using ornamental initials, ordinary body text and a readable print version. 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 ornate forms where students must distinguish similar characters or enter exact codes.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test zoom, contrast, copy-paste, screen-reader text and a plain-font fallback before release.” 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 font-variant-alternates syntax. For this chapter, useful prompts are: “What did you expect from Accessible design keeps meaning independent?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using ornate forms where students must distinguish similar characters or enter exact codes be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny project heading with a display typeface, a named stylistic alternate and a plain fallback. Include one ordinary case, one boundary and one deliberate failure caused by using ornate forms where students must distinguish similar characters or enter exact codes. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Accessible design keeps meaning independent, separate the documented CSS font-variant-alternates 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. project heading: model, boundary and recovery

Create a small project heading using a display typeface, a named stylistic alternate and a plain fallback. Combine “Characters and glyphs are different layers” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

2. library poster: model, boundary and recovery

Create a small library poster using ornamental initials, ordinary body text and a readable print version. Combine “historical-forms has a direct keyword” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

3. CCA badge: model, boundary and recovery

Create a small CCA badge using short team lettering, a controlled styleset and accessible text. Combine “character-variant() targets variant groups” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

4. science label: model, boundary and recovery

Create a small science label using stable characters, a character variant and copy-paste verification. Combine “annotation() selects alternate annotation forms” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

5. revision card: model, boundary and recovery

Create a small revision card using one decorative heading and unaffected explanation text. Combine “Fallbacks can remove the visible effect” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. family invitation: model, boundary and recovery

Create a small family invitation using a swash-capable font, conservative spacing and fallback testing. Combine “The font shorthand can reset subproperties” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. web article: model, boundary and recovery

Create a small web article using inherited typography, scoped overrides and browser inspection. Combine “Visual regression needs stable fonts and strings” 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-system specimen: model, boundary and recovery

Create a small design-system specimen using feature names, font files, screenshots and regression cases. Combine “The initial value is normal” 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 font-variant-alternates
• eduKatePunggol: How Studying Works

Return to contents