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 feature queries use @supports conditions to ask whether a browser accepts particular CSS syntax, allowing optional enhancements to be layered over a working baseline. Mastery means testing the exact capability a design depends on, grouping boolean conditions correctly, understanding that syntax support is not a promise of perfect behaviour, and preserving accessible fallback 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.

A feature query conditionally applies rules, so essential content and interaction should work before the conditional block is considered. 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 only usable layout or visible control inside @supports. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write and test the fallback first, then add one independently removable enhancement.

For the Baseline first, enhancement second chapter on CSS feature queries with @supports, 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 only usable layout or visible control inside @supports. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.cards{display:block}
@supports (display:grid){.cards{display:grid;grid-template-columns:repeat(2,1fr)}}

Four purposeful transfer cases

Case 1: homework cards. Predict the rule using a readable block layout enhanced to grid. 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 filters. Contrast the rule using plain controls enhanced with a supported selector. 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 timetable. Stress-test the rule using stacked sessions enhanced to columns. 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 chart. Explain the rule using text labels enhanced with advanced layout. 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 only usable layout or visible control inside @supports.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Write and test the fallback first, then add one independently removable enhancement.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Baseline first, enhancement second?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing placing the only usable layout or visible control inside @supports be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny budget table with scrollable rows enhanced with sticky presentation. Include one ordinary case, one boundary and one deliberate failure caused by placing the only usable layout or visible control inside @supports. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Baseline first, enhancement second, separate the documented CSS feature queries with @supports 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 parenthesised property-value declaration asks whether the implementation supports that declaration as CSS syntax. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating a true result as proof the design works in every content and accessibility case. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Match the query to the property-value pair used and still test layout behaviour.

For the Declaration conditions test syntax support chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on treating a true result as proof the design works in every content and accessibility case. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (display: grid){.panel{display:grid}}

Four purposeful transfer cases

Case 1: CCA timetable. Contrast the rule using stacked sessions enhanced to columns. 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 chart. Stress-test the rule using text labels enhanced with advanced layout. 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 tracker. Explain the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Transfer the rule using scrollable rows enhanced with sticky presentation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers treating a true result as proof the design works in every content and accessibility case.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Match the query to the property-value pair used and still test layout behaviour.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Declaration conditions test syntax support?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating a true result as proof the design works in every content and accessibility case be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport panel with a linear route enhanced with logical layout features. Include one ordinary case, one boundary and one deliberate failure caused by treating a true result as proof the design works in every content and accessibility case. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Declaration conditions test syntax support, separate the documented CSS feature queries with @supports 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

Simple declaration conditions are enclosed in parentheses, and grouping parentheses clarify compound boolean expressions. 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 dropping parentheses because the condition looks like an ordinary media query. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Format each atomic test on its own line and validate the complete stylesheet.

For the Parentheses are part of the grammar chapter on CSS feature queries with @supports, 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 dropping parentheses because the condition looks like an ordinary media query. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (gap: 1rem){.stack{gap:1rem}}

Four purposeful transfer cases

Case 1: revision tracker. Stress-test the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Explain the rule using scrollable rows enhanced with sticky presentation. 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: transport panel. Transfer the rule using a linear route enhanced with logical layout features. 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: debug page. Predict the rule using a baseline rule, a support condition and computed-style evidence. 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 dropping parentheses because the condition looks like an ordinary media query.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Format each atomic test on its own line and validate the complete stylesheet.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Parentheses are part of the grammar?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing dropping parentheses because the condition looks like an ordinary media query be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny debug page with a baseline rule, a support condition and computed-style evidence. Include one ordinary case, one boundary and one deliberate failure caused by dropping parentheses because the condition looks like an ordinary media query. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Parentheses are part of the grammar, separate the documented CSS feature queries with @supports 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 not operator reverses a support condition and is useful for a narrow repair when the baseline alone is insufficient. 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 not blocks to maintain an entire second design system. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep the baseline outside and limit the negative branch to one verified compatibility need.

For the not negates one condition chapter on CSS feature queries with @supports, 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 not blocks to maintain an entire second design system. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports not (display:grid){.cards{max-width:42rem}}

Four purposeful transfer cases

Case 1: transport panel. Explain the rule using a linear route enhanced with logical layout features. 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: debug page. Transfer the rule using a baseline rule, a support condition and computed-style evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework cards. Predict the rule using a readable block layout enhanced to grid. 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 filters. Contrast the rule using plain controls enhanced with a supported selector. 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 not blocks to maintain an entire second design system.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep the baseline outside and limit the negative branch to one verified compatibility need.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from not negates one condition?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using not blocks to maintain an entire second design system be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework cards with a readable block layout enhanced to grid. Include one ordinary case, one boundary and one deliberate failure caused by using not blocks to maintain an entire second design system. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For not negates one condition, separate the documented CSS feature queries with @supports mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

An and condition succeeds only when all component support tests are true. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is testing one feature while the enhancement also depends on another. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. List every indispensable capability and include each atomic test.

For the and requires every component chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing one feature while the enhancement also depends on another. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (display:grid) and (gap:1rem){.cards{display:grid;gap:1rem}}

Four purposeful transfer cases

Case 1: homework cards. Transfer the rule using a readable block layout enhanced to grid. 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 filters. Predict the rule using plain controls enhanced with a supported selector. 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 timetable. Contrast the rule using stacked sessions enhanced to columns. 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 chart. Stress-test the rule using text labels enhanced with advanced layout. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing one feature while the enhancement also depends on another.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “List every indispensable capability and include each atomic test.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from and requires every component?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing one feature while the enhancement also depends on another be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library filters with plain controls enhanced with a supported selector. Include one ordinary case, one boundary and one deliberate failure caused by testing one feature while the enhancement also depends on another. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For and requires every component, separate the documented CSS feature queries with @supports mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

An or condition succeeds when at least one alternative is supported, letting several acceptable implementations share a 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 assuming the later declarations automatically choose the supported alternative. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep vendor or alternative declarations inside with an ordered cascade and test which computes.

For the or allows alternatives chapter on CSS feature queries with @supports, 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 later declarations automatically choose the supported alternative. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (text-wrap:balance) or (text-wrap:pretty){h2{max-width:24ch}}

Four purposeful transfer cases

Case 1: CCA timetable. Predict the rule using stacked sessions enhanced to columns. 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 chart. Contrast the rule using text labels enhanced with advanced layout. 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 tracker. Stress-test the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Explain the rule using scrollable rows enhanced with sticky presentation. 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 later declarations automatically choose the supported alternative.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep vendor or alternative declarations inside with an ordered cascade and test which computes.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from or allows alternatives?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing assuming the later declarations automatically choose the supported alternative be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA timetable with stacked sessions enhanced to columns. Include one ordinary case, one boundary and one deliberate failure caused by assuming the later declarations automatically choose the supported alternative. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For or allows alternatives, separate the documented CSS feature queries with @supports 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 does not allow casual mixing of and and or without parentheses that make grouping unambiguous. 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 long condition with programming-language precedence assumptions. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Group alternatives first, then connect groups with the remaining operator.

For the Mixed boolean operators need explicit grouping chapter on CSS feature queries with @supports, 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 long condition with programming-language precedence assumptions. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports ((display:grid) and (gap:1rem)) or (display:flex){.layout{min-height:10rem}}

Four purposeful transfer cases

Case 1: revision tracker. Contrast the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Stress-test the rule using scrollable rows enhanced with sticky presentation. 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: transport panel. Explain the rule using a linear route enhanced with logical layout features. 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: debug page. Transfer the rule using a baseline rule, a support condition and computed-style evidence. 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 long condition with programming-language precedence assumptions.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Group alternatives first, then connect groups with the remaining operator.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Mixed boolean operators need explicit grouping?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing reading a long condition with programming-language precedence assumptions be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science chart with text labels enhanced with advanced layout. Include one ordinary case, one boundary and one deliberate failure caused by reading a long condition with programming-language precedence assumptions. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Mixed boolean operators need explicit grouping, separate the documented CSS feature queries with @supports mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

An unsupported or invalid property-value declaration makes that atomic support test false without invalidating the baseline stylesheet. 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 experimental syntax outside any fallback and expecting @supports elsewhere to rescue it. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Isolate the exact experimental declaration in the matching conditional block.

For the Unknown declarations make a false atom chapter on CSS feature queries with @supports, 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 experimental syntax outside any fallback and expecting @supports elsewhere to rescue it. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (unknown-property:magic){.note{color:green}}

Four purposeful transfer cases

Case 1: transport panel. Stress-test the rule using a linear route enhanced with logical layout features. 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: debug page. Explain the rule using a baseline rule, a support condition and computed-style evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework cards. Transfer the rule using a readable block layout enhanced to grid. 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 filters. Predict the rule using plain controls enhanced with a supported selector. 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 experimental syntax outside any fallback and expecting @supports elsewhere to rescue it.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Isolate the exact experimental declaration in the matching conditional block.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Unknown declarations make a false atom?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing putting experimental syntax outside any fallback and expecting @supports elsewhere to rescue it be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with a simple progress list enhanced with container-aware styling. Include one ordinary case, one boundary and one deliberate failure caused by putting experimental syntax outside any fallback and expecting @supports elsewhere to rescue it. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Unknown declarations make a false atom, separate the documented CSS feature queries with @supports 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

Support for a custom-property declaration proves the syntax is accepted, not that a value later substituted with var() is valid for every consuming 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 testing (–x: value) and claiming all uses of var(–x) are supported. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test the actual consuming declaration where possible and inspect computed style.

For the Custom properties need careful interpretation chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing (–x: value) and claiming all uses of var(–x) are supported. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

:root{--layout:grid}
@supports (display:var(--layout)){.panel{display:var(--layout)}}

Four purposeful transfer cases

Case 1: homework cards. Explain the rule using a readable block layout enhanced to grid. 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 filters. Transfer the rule using plain controls enhanced with a supported selector. 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 timetable. Predict the rule using stacked sessions enhanced to columns. 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 chart. Contrast the rule using text labels enhanced with advanced layout. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing (–x: value) and claiming all uses of var(–x) are supported.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test the actual consuming declaration where possible and inspect computed style.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Custom properties need careful interpretation?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing (–x: value) and claiming all uses of var(–x) are supported be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny budget table with scrollable rows enhanced with sticky presentation. Include one ordinary case, one boundary and one deliberate failure caused by testing (–x: value) and claiming all uses of var(–x) are supported. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Custom properties need careful interpretation, separate the documented CSS feature queries with @supports 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 selector() support function can test whether a selector grammar is supported before rules depending on it are applied. 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 selector itself outside the feature query where an older parser may discard the whole rule. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep both the selector-dependent rule and its test inside a progressive enhancement boundary.

For the selector() tests selector syntax chapter on CSS feature queries with @supports, 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 selector itself outside the feature query where an older parser may discard the whole rule. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports selector(:has(*)){.card:has(img){padding-top:0}}

Four purposeful transfer cases

Case 1: CCA timetable. Transfer the rule using stacked sessions enhanced to columns. 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 chart. Predict the rule using text labels enhanced with advanced layout. 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 tracker. Contrast the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Stress-test the rule using scrollable rows enhanced with sticky presentation. 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 selector itself outside the feature query where an older parser may discard the whole rule.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep both the selector-dependent rule and its test inside a progressive enhancement boundary.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from selector() tests selector syntax?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing placing the selector itself outside the feature query where an older parser may discard the whole rule be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport panel with a linear route enhanced with logical layout features. Include one ordinary case, one boundary and one deliberate failure caused by placing the selector itself outside the feature query where an older parser may discard the whole rule. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For selector() tests selector syntax, separate the documented CSS feature queries with @supports 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

Newer conditional syntax can test font technology or format support, but availability varies and requires target-browser evidence. 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 specialised tests without a robust font fallback stack. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Keep a normal font face and stack, then conditionally add only the optional resource.

For the font-tech() and font-format() are specialised tests chapter on CSS feature queries with @supports, 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 specialised tests without a robust font fallback stack. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports font-tech(color-COLRv1){/* optional colour-font enhancement */}

Four purposeful transfer cases

Case 1: revision tracker. Predict the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Contrast the rule using scrollable rows enhanced with sticky presentation. 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: transport panel. Stress-test the rule using a linear route enhanced with logical layout features. 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: debug page. Explain the rule using a baseline rule, a support condition and computed-style evidence. 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 specialised tests without a robust font fallback stack.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Keep a normal font face and stack, then conditionally add only the optional resource.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from font-tech() and font-format() are specialised tests?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing using specialised tests without a robust font fallback stack be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny debug page with a baseline rule, a support condition and computed-style evidence. Include one ordinary case, one boundary and one deliberate failure caused by using specialised tests without a robust font fallback stack. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For font-tech() and font-format() are specialised tests, separate the documented CSS feature queries with @supports mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

An @supports rule nested inside another conditional context applies only when every enclosing condition is active. 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 forgetting a media or container condition outside the feature query while debugging. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Write the active-condition stack and test one boundary at a time.

For the Nested feature queries form an intersection chapter on CSS feature queries with @supports, 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 forgetting a media or container condition outside the feature query while debugging. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@media (min-width:50rem){@supports (display:grid){.cards{display:grid}}}

Four purposeful transfer cases

Case 1: transport panel. Contrast the rule using a linear route enhanced with logical layout features. 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: debug page. Stress-test the rule using a baseline rule, a support condition and computed-style evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework cards. Explain the rule using a readable block layout enhanced to grid. 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 filters. Transfer the rule using plain controls enhanced with a supported selector. 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 forgetting a media or container condition outside the feature query while debugging.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Write the active-condition stack and test one boundary at a time.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Nested feature queries form an intersection?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing forgetting a media or container condition outside the feature query while debugging be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework cards with a readable block layout enhanced to grid. Include one ordinary case, one boundary and one deliberate failure caused by forgetting a media or container condition outside the feature query while debugging. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Nested feature queries form an intersection, separate the documented CSS feature queries with @supports 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 true feature query merely makes its declarations participate; origin, importance, layer, specificity and source order still choose the result. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is blaming a false support condition when a later rule overrides the enhancement. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Check whether the block matched, then inspect computed style and cascade order separately.

For the The cascade still decides winners chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on blaming a false support condition when a later rule overrides the enhancement. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

.box{display:block}
@supports (display:grid){.box{display:grid}}
.box.special{display:block}

Four purposeful transfer cases

Case 1: homework cards. Stress-test the rule using a readable block layout enhanced to grid. 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 filters. Explain the rule using plain controls enhanced with a supported selector. 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 timetable. Transfer the rule using stacked sessions enhanced to columns. 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 chart. Predict the rule using text labels enhanced with advanced layout. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers blaming a false support condition when a later rule overrides the enhancement.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Check whether the block matched, then inspect computed style and cascade order 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from The cascade still decides winners?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing blaming a false support condition when a later rule overrides the enhancement be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny library filters with plain controls enhanced with a supported selector. Include one ordinary case, one boundary and one deliberate failure caused by blaming a false support condition when a later rule overrides the enhancement. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For The cascade still decides winners, separate the documented CSS feature queries with @supports 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

@layer can give baseline, component and enhancement rules predictable priority independent of selector arms races. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is adding higher specificity inside every feature query to force it through. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Declare layer order and keep selectors comparable across the policy.

For the Cascade layers can organise enhancement policy chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on adding higher specificity inside every feature query to force it through. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@layer base,enhance;
@layer base{.cards{display:block}}
@layer enhance{@supports (display:grid){.cards{display:grid}}}

Four purposeful transfer cases

Case 1: CCA timetable. Explain the rule using stacked sessions enhanced to columns. 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 chart. Transfer the rule using text labels enhanced with advanced layout. 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 tracker. Predict the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Contrast the rule using scrollable rows enhanced with sticky presentation. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers adding higher specificity inside every feature query to force it through.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Declare layer order and keep selectors comparable across the policy.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Cascade layers can organise enhancement policy?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing adding higher specificity inside every feature query to force it through be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny CCA timetable with stacked sessions enhanced to columns. Include one ordinary case, one boundary and one deliberate failure caused by adding higher specificity inside every feature query to force it through. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Cascade layers can organise enhancement policy, separate the documented CSS feature queries with @supports 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

CSS.supports can test a declaration or condition string when script genuinely needs to coordinate behaviour with CSS capability. 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 duplicating all styling decisions in JavaScript and creating two sources of truth. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Let CSS own presentation; use script only when application logic needs the capability result.

For the CSS.supports brings the same question to JavaScript chapter on CSS feature queries with @supports, 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 duplicating all styling decisions in JavaScript and creating two sources of truth. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

CSS.supports('display','grid')
CSS.supports('(display: grid) and (gap: 1rem)')

Four purposeful transfer cases

Case 1: revision tracker. Transfer the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Predict the rule using scrollable rows enhanced with sticky presentation. 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: transport panel. Contrast the rule using a linear route enhanced with logical layout features. 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: debug page. Stress-test the rule using a baseline rule, a support condition and computed-style evidence. 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 duplicating all styling decisions in JavaScript and creating two sources of truth.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Let CSS own presentation; use script only when application logic needs the capability result.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from CSS.supports brings the same question to JavaScript?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing duplicating all styling decisions in JavaScript and creating two sources of truth be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny science chart with text labels enhanced with advanced layout. Include one ordinary case, one boundary and one deliberate failure caused by duplicating all styling decisions in JavaScript and creating two sources of truth. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For CSS.supports brings the same question to JavaScript, separate the documented CSS feature queries with @supports 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 can parse a feature yet have limitations, bugs, partial details or interactions that matter to the design. 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 equating true with accessible, bug-free and visually identical. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Combine feature detection with representative rendering, keyboard, zoom and content tests.

For the Support is not a complete correctness guarantee chapter on CSS feature queries with @supports, 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 equating true with accessible, bug-free and visually identical. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (position:sticky){th{position:sticky;top:0}}

Four purposeful transfer cases

Case 1: transport panel. Predict the rule using a linear route enhanced with logical layout features. 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: debug page. Contrast the rule using a baseline rule, a support condition and computed-style evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework cards. Stress-test the rule using a readable block layout enhanced to grid. 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 filters. Explain the rule using plain controls enhanced with a supported selector. 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 equating true with accessible, bug-free and visually identical.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Combine feature detection with representative rendering, keyboard, zoom and content tests.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Support is not a complete correctness guarantee?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing equating true with accessible, bug-free and visually identical be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny revision tracker with a simple progress list enhanced with container-aware styling. Include one ordinary case, one boundary and one deliberate failure caused by equating true with accessible, bug-free and visually identical. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Support is not a complete correctness guarantee, separate the documented CSS feature queries with @supports 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

Test the smallest exact feature on which the enhancement depends, not a famous proxy feature from the same browser era. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is testing display:grid as a stand-in for unrelated selector or colour support. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Trace each enhancement declaration to its own required capability.

For the Queries should match the dependency chapter on CSS feature queries with @supports, use a two-column trace during a short Punggol home session. On the left, write the predicted state for this exact mechanism before the tool runs. On the right, record the observation that bears on testing display:grid as a stand-in for unrelated selector or colour support. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (color:oklch(50% .1 200)){.badge{color:oklch(50% .1 200)}}

Four purposeful transfer cases

Case 1: homework cards. Contrast the rule using a readable block layout enhanced to grid. 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 filters. Stress-test the rule using plain controls enhanced with a supported selector. 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 timetable. Explain the rule using stacked sessions enhanced to columns. 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 chart. Transfer the rule using text labels enhanced with advanced layout. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Diagnostic route

• Model check: ask the learner to draw or list the exact rows, fields, references, paths or states involved.
• Boundary check: create the smallest input that triggers testing display:grid as a stand-in for unrelated selector or colour support.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Trace each enhancement declaration to its own required capability.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Queries should match the dependency?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing testing display:grid as a stand-in for unrelated selector or colour support be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny budget table with scrollable rows enhanced with sticky presentation. Include one ordinary case, one boundary and one deliberate failure caused by testing display:grid as a stand-in for unrelated selector or colour support. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Queries should match the dependency, separate the documented CSS feature queries with @supports 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

Feature queries answer capability questions more robustly than branching on browser names and versions. 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 maintaining a list of browser strings that becomes wrong as engines update. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Ask for the capability, preserve a baseline and test real supported targets.

For the Avoid user-agent sniffing chapter on CSS feature queries with @supports, 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 maintaining a list of browser strings that becomes wrong as engines update. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (aspect-ratio:1/1){.thumb{aspect-ratio:1/1}}

Four purposeful transfer cases

Case 1: CCA timetable. Stress-test the rule using stacked sessions enhanced to columns. 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 chart. Explain the rule using text labels enhanced with advanced layout. 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 tracker. Transfer the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Predict the rule using scrollable rows enhanced with sticky presentation. 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 maintaining a list of browser strings that becomes wrong as engines update.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Ask for the capability, preserve a baseline and test real supported targets.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Avoid user-agent sniffing?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing maintaining a list of browser strings that becomes wrong as engines update be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny transport panel with a linear route enhanced with logical layout features. Include one ordinary case, one boundary and one deliberate failure caused by maintaining a list of browser strings that becomes wrong as engines update. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Avoid user-agent sniffing, separate the documented CSS feature queries with @supports 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

Conditional CSS must not hide essential content, remove focus visibility or make controls depend on visual layout alone. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is treating enhancement as harmless because it is only CSS. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Test reading order, focus order, zoom, contrast and reduced motion in both branches.

For the Accessibility remains a design requirement chapter on CSS feature queries with @supports, 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 enhancement as harmless because it is only CSS. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

@supports (display:grid){.form{display:grid}}
:focus-visible{outline:3px solid currentColor}

Four purposeful transfer cases

Case 1: revision tracker. Explain the rule using a simple progress list enhanced with container-aware styling. 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: budget table. Transfer the rule using scrollable rows enhanced with sticky presentation. 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: transport panel. Predict the rule using a linear route enhanced with logical layout features. 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: debug page. Contrast the rule using a baseline rule, a support condition and computed-style evidence. 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 enhancement as harmless because it is only CSS.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Test reading order, focus order, zoom, contrast and reduced motion in both branches.” 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 feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from Accessibility remains a design requirement?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing treating enhancement as harmless because it is only CSS be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny debug page with a baseline rule, a support condition and computed-style evidence. Include one ordinary case, one boundary and one deliberate failure caused by treating enhancement as harmless because it is only CSS. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For Accessibility remains a design requirement, separate the documented CSS feature queries with @supports 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

Reliable feature-query work verifies baseline appearance, condition truth, parsed inner declarations, cascade outcome and task completion across target browsers. Treat that sentence as a testable model. A secure learner can point to the relevant input, name the operation, describe the resulting state and identify one observation that would prove the model incomplete.

The high-value mistake in this chapter is toggling random properties until one screenshot looks correct. It matters because the output may look reasonable while the ownership, ordering, identity or safety rule is wrong. Record the query result, computed value and user-task outcome for one controlled fixture per target.

For the A browser-matrix debugging workflow chapter on CSS feature queries with @supports, 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 toggling random properties until one screenshot looks correct. Explain the earliest difference with one causal sentence, then repeat only the smallest changed case.

Core worked example

console.table({grid:CSS.supports('display','grid'),has:CSS.supports('selector(:has(*))')});

Four purposeful transfer cases

Case 1: transport panel. Transfer the rule using a linear route enhanced with logical layout features. 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: debug page. Predict the rule using a baseline rule, a support condition and computed-style evidence. State the input grain or object graph, the chapter boundary and the intended output before choosing syntax. Change only one variable, so a wrong prediction has a single plausible cause.

Case 3: homework cards. Contrast the rule using a readable block layout enhanced to grid. 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 filters. Stress-test the rule using plain controls enhanced with a supported selector. 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 toggling random properties until one screenshot looks correct.
• Evidence check: separate a printed value from identity, ordering, ownership, type or repository state.
• Repair check: use the reversible procedure “Record the query result, computed value and user-task outcome for one controlled fixture per target.” and record the first changed observation.
• Transfer check: repeat the rule in a second context and identify what remains invariant.

A parent does not need to know the final CSS feature queries with @supports syntax. For this chapter, useful prompts are: “What did you expect from A browser-matrix debugging workflow?”, “Which state changed first?”, “What evidence tests that prediction?”, and “Can the case exposing toggling random properties until one screenshot looks correct be made smaller?” The learner, not the parent, should supply the technical explanation.

Practice with an explained answer

Question. Build a tiny homework cards with a readable block layout enhanced to grid. Include one ordinary case, one boundary and one deliberate failure caused by toggling random properties until one screenshot looks correct. Predict each result before using a tool, then report the first point where observation differs from prediction.

Decision and transfer

For A browser-matrix debugging workflow, separate the documented CSS feature queries with @supports mechanism from the project policy. State exactly what the technical contract guarantees, then state the project choice about validation, ordering, ownership, performance or recovery. Test whether the same distinction survives one transfer case, and keep stateful experiments disposable and backed up.

Previous chapter . Contents . Next chapter

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

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

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

1. homework cards: model, boundary and recovery

Create a small homework cards using a readable block layout enhanced to grid. Combine “Baseline first, enhancement second” 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 filters: model, boundary and recovery

Create a small library filters using plain controls enhanced with a supported selector. Combine “not negates one condition” 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 timetable: model, boundary and recovery

Create a small CCA timetable using stacked sessions enhanced to columns. Combine “Mixed boolean operators need explicit grouping” 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 chart: model, boundary and recovery

Create a small science chart using text labels enhanced with advanced layout. Combine “selector() tests selector syntax” 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 tracker: model, boundary and recovery

Create a small revision tracker using a simple progress list enhanced with container-aware styling. Combine “The cascade still decides winners” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

6. budget table: model, boundary and recovery

Create a small budget table using scrollable rows enhanced with sticky presentation. Combine “Support is not a complete correctness guarantee” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

7. transport panel: model, boundary and recovery

Create a small transport panel using a linear route enhanced with logical layout features. Combine “Accessibility remains a design requirement” with one later chapter. Include an ordinary case, a boundary, a deliberate failure and a recovery. Write the expected state before each operation.

8. debug page: model, boundary and recovery

Create a small debug page using a baseline rule, a support condition and computed-style evidence. Combine “Declaration conditions test syntax support” 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 feature queries with @supports
• eduKatePunggol: How Studying Works

Return to contents