A style query can match an ancestor’s computed custom-property value while a descendant inherits or overrides its own value. When those values happen to agree, it is easy to mistake one mechanism for the other.
This guide follows container selection, computed-value comparison, cascade, inheritance and var() substitution as separate stages. Original nested-component examples show where a query can stay true while the rendered descendant changes.
Style queries remain an evolving web-platform feature. The explanation follows the current W3C specifications and asks readers to test support and reduced cases in their target browsers.
The apparent puzzle begins when a component uses the same custom property in two ways. An ancestor value can be tested by a style query, while that value or another token can flow down to descendants through inheritance and var() substitution. When the screen looks correct, both paths are easy to collapse into one vague idea of “the theme variable”.
This guide follows the browser pipeline in order. It identifies the selected query container, computes the property on that element, evaluates the condition, admits the enclosed declarations to the cascade, computes properties on the styled descendant and then follows inheritance. A failure at each stage produces a different devtools signature and needs a different repair.
The worked dark-theme component deliberately changes only one element at a time. Overriding the text token on the label changes the text without changing the panel query. Moving the theme override onto the queried panel can change the condition. Registering the property with inherits:false creates a third outcome that ordinary unregistered-property intuition would miss.
The learner’s evidence receipt records two element paths: the ancestor path used for container selection and the descendant path used for cascade and inheritance. It also records query truth separately from the winning declaration. That separation explains how a condition can be true while another cascade layer still controls the rendered colour.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their numbers are stipulated so that the reasoning can be checked.
eduKateSG · Websites
Find your next learning step
Read the short answer first: a style query tests the selected ancestor container; inheritance supplies a computed value to a descendant when its own cascade does not override it. Trace the two elements and two operations separately before debugging the visual result.
ROUTE 1 · CHAPTERS 1–4
Define the quantities
Name the quantities, reference conditions and reporting rules.
ROUTE 3 · CHAPTERS 9–12
Audit the evidence
Check instruments, algorithms, assumptions and rival explanations.
ROUTE 5 · CHAPTERS 17–20
Report and continue
Repair shortcuts, answer questions and follow verified routes.
Chapter contents
Define the quantities · Chapters 1–4
1. Name the queried value and inherited value
2. Find the selected style container
Work the mechanism · Chapters 5–8
5. Work the central inherited-theme case
6. Follow inheritance one element at a time
Audit the evidence · Chapters 9–12
10. Audit the custom-property cascade
Transfer the reasoning · Chapters 13–16
13. Transfer to component variants
Report and continue · Chapters 17–20
17. Repair the descendant-controls-ancestor shortcut
18. Repair the inherited-means-same-everywhere shortcut
CHAPTER 1 OF 20 · Define the quantities
1. Name the queried value and inherited value
A container style query tests a computed value on the selected query container. A descendant using var() reads the custom property’s computed value on that descendant, often inherited from its parent. The two operations can agree without being the same lookup.
Write the evidence in the order a reader can audit: the Websites quantity, its reference object, the observation or browser rule, the transformation, and the decision being made. Keeping those fields visible prevents a familiar label from hiding a changed basis.
Worked example: .theme sets –tone:dark. A child is inside @container style(–tone:dark) and also uses color:var(–ink). Record the query container’s –tone and the child’s inherited –ink separately.
First-principles test: ask what physical, observational or algorithmic operation produces each value in this chapter. Then ask whether the second value could change while the first stays fixed. If it can, the two labels are not substitutes. For Websites, this counterfactual is often clearer than a definition learned in isolation.
Changed-context check: override –ink on the child. Its color changes while the ancestor style query can remain true.
Evidence check: another reader should be able to reproduce the narrow result from the stored definitions, inputs and intermediate steps, then identify the nearest stronger claim that the evidence does not support.
Limit: style-query support and interoperable details must be checked against current browsers and specifications.
Elements are style query containers by default for style features, but container names can filter selection. The selected ancestor, not the styled descendant, supplies the property value tested by the condition.
Trace the mechanism before interpreting the result. For Websites, mark which value belongs to the source, which belongs to the measurement or layout algorithm, and which is a reported summary. A calculation is useful only when those roles remain attached.
Nest .card inside .theme and query @container theme style(–tone:dark). Mark .theme as the selected container even though .card receives the rule.
Practical transfer: build two records that share the headline number but differ in the condition discussed here. If the correct interpretation changes, the omitted condition is decision-relevant and belongs in the report. This test turns a vocabulary distinction into a reusable Websites checking habit.
Insert a nearer unnamed ancestor. A named query still searches for the matching name.
Practical check: keep one counterexample beside the worked case. If the wording fails when that one condition changes, narrow the sentence until it describes only the evidence actually in hand.
Limit: query-container selection follows the shadow-including tree rules defined by the specification.
CHAPTER 3 OF 20 · Define the quantities
3. Separate query truth from cascade outcome
A true @container condition only makes enclosed declarations eligible for the cascade. Specificity, origin, importance, layers, order and invalid computed values still determine the final property.
Use a compact decision table with columns for condition, input, operation, result and limit. This makes the comparison reproducible and exposes where a missing field would force an assumption instead of an observation.
The query activates color:var(–ink), but a later same-layer rule sets color:blue. The query is true while the final color is blue.
Misconception check: a plausible output does not prove the right reference, denominator, ancestor, spectrum or observation rule was used. Reconstruct one intermediate step and one changed-context prediction. If either cannot be stated, keep the result provisional rather than strengthening its wording.
Move the competing rule into a lower-priority layer and recompute.
Transfer check: repeat the reasoning with one consequential condition changed while holding the rest fixed. State what changes, what stays comparable and why the original label alone was insufficient.
Limit: browser devtools may display matched rules differently; inspect the computed result.
CHAPTER 4 OF 20 · Define the quantities
4. Track computed values, not source spelling
Style features compare computed values on the query container. Two declarations with different source text can compute equally, while identical tokens can compute differently under distinct custom-property environments.
Preserve the raw inputs beside the derived result. If a later reader changes one condition, the original Websites reasoning should still be recoverable without reverse-engineering a rounded headline or an unlabeled screenshot.
Set –gap:calc(8px + 8px) on the container and query style(–gap:16px) only where the specification’s computed-value rules support the match. Record the actual computed representation.
Evidence design: retain both a positive case and a near-miss. The positive case shows when the rule applies; the near-miss changes one consequential condition and shows when the conclusion fails. Together they teach the boundary of the Websites mechanism better than another unlabelled example.
Change a referenced custom property from 8px to 10px and re-evaluate.
Audit check: retain the source version, units, settings, exclusions and rounding rule. A future correction should be able to alter one field without rebuilding the entire explanation from memory.
Limit: value serialization and supported queryable properties remain specification and implementation concerns.
The central DOM has .shell{–tone:dark;–ink:white}, .panel inheriting both, and .label inside the panel. A style query on the panel for –tone:dark activates a border; .label uses var(–ink) for text.
Ask what would have to stay fixed for the comparison to be fair. Record those controls explicitly, then name the first uncontrolled condition that could reverse the conclusion. This is the practical transfer step, not an optional footnote.
Create a ledger: panel queried tone dark; condition true; border rule eligible; label computed ink white by inheritance. No step requires the label to be the queried container.
Communication test: replace any sentence that says two things are “the same” or “different” with a sentence naming the operation, reference condition and supported consequence. The extra words are useful when they let a future reader repeat the decision without access to the original author.
Override –ink:black on .label. The border remains activated by panel tone.
Decision check: end with an action or interpretation that follows from the stated conditions, followed by a boundary sentence explaining when a specialist rule, local procedure or additional measurement is needed.
Limit: the code is a teaching case and should be tested in target browsers.
Unregistered custom properties inherit by default. Each element receives a computed value through cascade and inheritance, and var() substitutes from the property on the same element where it is used. Skipping levels can hide an override.
Write the evidence in the order a reader can audit: the Websites quantity, its reference object, the observation or browser rule, the transformation, and the decision being made. Keeping those fields visible prevents a familiar label from hiding a changed basis.
Trace –ink from .shell white to .panel white to .label white. Add .panel{–ink:ivory} and update the last two rows.
First-principles test: ask what physical, observational or algorithmic operation produces each value in this chapter. Then ask whether the second value could change while the first stays fixed. If it can, the two labels are not substitutes. For Websites, this counterfactual is often clearer than a definition learned in isolation.
Add a child override and verify only descendants of that child inherit it.
Evidence check: another reader should be able to reproduce the narrow result from the stored definitions, inputs and intermediate steps, then identify the nearest stronger claim that the evidence does not support.
Limit: registered custom properties can specify different inheritance behaviour.
The Properties and Values API can register a custom property with syntax, initial value and inherits:false. A style query may therefore see a computed value that differs from what ordinary inherited-variable intuition predicts.
Trace the mechanism before interpreting the result. For Websites, mark which value belongs to the source, which belongs to the measurement or layout algorithm, and which is a reported summary. A calculation is useful only when those roles remain attached.
Register –mode with inherits:false and initial light. Set dark on .shell; a nested panel without its own declaration computes light.
Practical transfer: build two records that share the headline number but differ in the condition discussed here. If the correct interpretation changes, the omitted condition is decision-relevant and belongs in the report. This test turns a vocabulary distinction into a reusable Websites checking habit.
Change the registration to inherits:true in a controlled test and compare the query result.
Practical check: keep one counterexample beside the worked case. If the wording fails when that one condition changes, narrow the sentence until it describes only the evidence actually in hand.
Limit: @property registration validity and initial values must satisfy the specification.
CHAPTER 8 OF 20 · Work the mechanism
8. Handle invalid and unsupported style features
A style query can evaluate unknown when the property or value is invalid or unsupported. Unknown is not the same as false, especially when combined with not, and, or. Preserve three-valued logic in debugging notes.
Use a compact decision table with columns for condition, input, operation, result and limit. This makes the comparison reproducible and exposes where a missing field would force an assumption instead of an observation.
Query an unsupported property and record unknown. Do not label the condition simply false before applying the conditional-logic rules.
Misconception check: a plausible output does not prove the right reference, denominator, ancestor, spectrum or observation rule was used. Reconstruct one intermediate step and one changed-context prediction. If either cannot be stated, keep the result provisional rather than strengthening its wording.
Replace the feature with a supported custom-property query and observe whether truth becomes determinate.
Transfer check: repeat the reasoning with one consequential condition changed while holding the rest fixed. State what changes, what stays comparable and why the original label alone was insufficient.
Limit: supported style features are evolving; verify the current specification and implementation.
container-name is not inherited. A name filters which ancestor can be selected, while the custom property being queried may itself be inherited. Mixing these two inheritance stories creates hard-to-see bugs.
Preserve the raw inputs beside the derived result. If a later reader changes one condition, the original Websites reasoning should still be recoverable without reverse-engineering a rounded headline or an unlabeled screenshot.
Set container-name:theme on .shell and –tone:dark on :root. The shell can inherit tone but its name comes from its own declaration.
Evidence design: retain both a positive case and a near-miss. The positive case shows when the rule applies; the near-miss changes one consequential condition and shows when the conclusion fails. Together they teach the boundary of the Websites mechanism better than another unlabelled example.
Remove the name while keeping –tone. The named query loses its eligible container.
Audit check: retain the source version, units, settings, exclusions and rounding rule. A future correction should be able to alter one field without rebuilding the entire explanation from memory.
Limit: multiple names and nested conditions require a complete ancestor trace.
Custom properties participate in the cascade. Layers, specificity and importance choose the cascaded declaration before inheritance and substitution. A style query reflects the resulting computed value, not the declaration a developer expected to win.
Ask what would have to stay fixed for the comparison to be fair. Record those controls explicitly, then name the first uncontrolled condition that could reverse the conclusion. This is the practical transfer step, not an optional footnote.
Place –tone:dark in a low layer and –tone:light in a higher layer on the same container. The query for dark should be checked against light.
Communication test: replace any sentence that says two things are “the same” or “different” with a sentence naming the operation, reference condition and supported consequence. The extra words are useful when they let a future reader repeat the decision without access to the original author.
Reverse layer order without changing selectors and recompute.
Decision check: end with an action or interpretation that follows from the stated conditions, followed by a boundary sentence explaining when a specialist rule, local procedure or additional measurement is needed.
Limit: transitions and animations can add time-varying computed values.
Custom-property values can contain var() references. Substitution and cycle handling occur during value computation. A query that appears to test one token may depend on another property and become invalid when the dependency is missing or cyclic.
Write the evidence in the order a reader can audit: the Websites quantity, its reference object, the observation or browser rule, the transformation, and the decision being made. Keeping those fields visible prevents a familiar label from hiding a changed basis.
Set –tone:var(–preferred); –preferred:dark. Then remove –preferred and inspect the guaranteed-invalid result before evaluating the query.
First-principles test: ask what physical, observational or algorithmic operation produces each value in this chapter. Then ask whether the second value could change while the first stays fixed. If it can, the two labels are not substitutes. For Websites, this counterfactual is often clearer than a definition learned in isolation.
Add a fallback var(–preferred,dark) and compare.
Evidence check: another reader should be able to reproduce the narrow result from the stored definitions, inputs and intermediate steps, then identify the nearest stronger claim that the evidence does not support.
Limit: fallbacks repair missing substitution, not every invalid final property value.
Container queries use defined shadow-including relationships, while custom properties cross shadow boundaries through inheritance according to the tree and exposed styling contract. A component API should document which property is queried and where.
Trace the mechanism before interpreting the result. For Websites, mark which value belongs to the source, which belongs to the measurement or layout algorithm, and which is a reported summary. A calculation is useful only when those roles remain attached.
Put a slotted label inside a named theme host. Trace the selected container and the label’s inherited variable separately.
Practical transfer: build two records that share the headline number but differ in the condition discussed here. If the correct interpretation changes, the omitted condition is decision-relevant and belongs in the report. This test turns a vocabulary distinction into a reusable Websites checking habit.
Move the variable declaration from host to an internal wrapper and test whether the slotted node still receives it.
Practical check: keep one counterexample beside the worked case. If the wording fails when that one condition changes, narrow the sentence until it describes only the evidence actually in hand.
Limit: component structure and browser tooling can make boundary mistakes difficult to diagnose.
A component can expose –density:compact on a container, then use a style query to enable a compact descendant layout. Descendants may also inherit –density for their own declarations, but the query remains an ancestor test.
Use a compact decision table with columns for condition, input, operation, result and limit. This makes the comparison reproducible and exposes where a missing field would force an assumption instead of an observation.
Set –density:compact on one card and comfortable on another. Confirm only the first query block applies, then inspect inherited values in both.
Misconception check: a plausible output does not prove the right reference, denominator, ancestor, spectrum or observation rule was used. Reconstruct one intermediate step and one changed-context prediction. If either cannot be stated, keep the result provisional rather than strengthening its wording.
Override –density on a grandchild and verify it cannot retroactively change the ancestor query.
Transfer check: repeat the reasoning with one consequential condition changed while holding the rest fixed. State what changes, what stays comparable and why the original label alone was insufficient.
Limit: avoid creating circular expectations where descendants are supposed to restyle the queried ancestor.
Design tokens stored as custom properties can drive both direct substitution and conditional component behaviour. Keep token definition, query container and consuming descendant visible so a theme override has predictable scope.
Preserve the raw inputs beside the derived result. If a later reader changes one condition, the original Websites reasoning should still be recoverable without reverse-engineering a rounded headline or an unlabeled screenshot.
Use –surface:dark to activate a light-border rule and –text:on-dark for descendant text. Change only –text to demonstrate independent consumption.
Evidence design: retain both a positive case and a near-miss. The positive case shows when the rule applies; the near-miss changes one consequential condition and shows when the conclusion fails. Together they teach the boundary of the Websites mechanism better than another unlabelled example.
Move the token override to a narrower subtree and map which components change.
Audit check: retain the source version, units, settings, exclusions and rounding rule. A future correction should be able to alter one field without rebuilding the entire explanation from memory.
Limit: semantic tokens and raw colour values need accessibility checks beyond query truth.
Nested container queries can select different ancestors. A size query may use a named card while an inner style query uses the nearest style container. Combining them mentally into one ancestor can produce a wrong explanation.
Ask what would have to stay fixed for the comparison to be fair. Record those controls explicitly, then name the first uncontrolled condition that could reverse the conclusion. This is the practical transfer step, not an optional footnote.
Nest @container card (inline-size>30rem) around @container style(–tone:dark). Record the selected container for each condition.
Communication test: replace any sentence that says two things are “the same” or “different” with a sentence naming the operation, reference condition and supported consequence. The extra words are useful when they let a future reader repeat the decision without access to the original author.
Insert a nearer style container with light tone; only the inner condition should change.
Decision check: end with an action or interpretation that follows from the stated conditions, followed by a boundary sentence explaining when a specialist rule, local procedure or additional measurement is needed.
Limit: nested query complexity can justify refactoring or explicit names.
A robust component starts with usable base styles. Style-query rules add an enhancement when the browser and container provide a determinate matching value. The base should not depend on an unsupported query becoming false in a particular way.
Write the evidence in the order a reader can audit: the Websites quantity, its reference object, the observation or browser rule, the transformation, and the decision being made. Keeping those fields visible prevents a familiar label from hiding a changed basis.
Give .panel a base border and replace it with a theme-specific border inside the query. Test in a browser without style-query support.
First-principles test: ask what physical, observational or algorithmic operation produces each value in this chapter. Then ask whether the second value could change while the first stays fixed. If it can, the two labels are not substitutes. For Websites, this counterfactual is often clearer than a definition learned in isolation.
Remove the custom-property declaration and verify the base remains readable.
Evidence check: another reader should be able to reproduce the narrow result from the stored definitions, inputs and intermediate steps, then identify the nearest stronger claim that the evidence does not support.
Limit: support detection and fallbacks need current compatibility testing.
CHAPTER 17 OF 20 · Report and continue
17. Repair the descendant-controls-ancestor shortcut
A descendant’s custom-property override affects that descendant and its subtree. It does not change the computed value already queried on an ancestor, so it cannot flip the ancestor condition backward.
Trace the mechanism before interpreting the result. For Websites, mark which value belongs to the source, which belongs to the measurement or layout algorithm, and which is a reported summary. A calculation is useful only when those roles remain attached.
Set –tone:light on .label inside a dark .panel. The panel query stays true even though the label now computes light.
Practical transfer: build two records that share the headline number but differ in the condition discussed here. If the correct interpretation changes, the omitted condition is decision-relevant and belongs in the report. This test turns a vocabulary distinction into a reusable Websites checking habit.
Move the override from label to panel and observe that the query can change.
Practical check: keep one counterexample beside the worked case. If the wording fails when that one condition changes, narrow the sentence until it describes only the evidence actually in hand.
Limit: declarations inside a true query can affect descendants and create indirect visual feedback.
CHAPTER 18 OF 20 · Report and continue
18. Repair the inherited-means-same-everywhere shortcut
Inheritance supplies a default computed value down a path, but any element can win a different cascade result. Registered properties can also disable inheritance. Always inspect the exact element used for query or substitution.
Use a compact decision table with columns for condition, input, operation, result and limit. This makes the comparison reproducible and exposes where a missing field would force an assumption instead of an observation.
Trace three elements where values are dark, dark and light after a child override. Replace the tree-wide statement with element-specific records.
Misconception check: a plausible output does not prove the right reference, denominator, ancestor, spectrum or observation rule was used. Reconstruct one intermediate step and one changed-context prediction. If either cannot be stated, keep the result provisional rather than strengthening its wording.
Register the property with inherits:false and repeat the trace.
Transfer check: repeat the reasoning with one consequential condition changed while holding the rest fixed. State what changes, what stays comparable and why the original label alone was insufficient.
Limit: computed styles can vary over time with animations or state changes.
CHAPTER 19 OF 20 · Report and continue
19. State the supported debugging conclusion
A defensible report names the styled element, selected query container, container name, queried property, computed value, condition result, winning declarations and descendant inheritance path. It distinguishes a false query from a losing or invalid declaration.
Preserve the raw inputs beside the derived result. If a later reader changes one condition, the original Websites reasoning should still be recoverable without reverse-engineering a rounded headline or an unlabeled screenshot.
Write: “The panel computes –tone:dark, so the style query is true; the label still renders blue because a later cascade rule wins color.”
Evidence design: retain both a positive case and a near-miss. The positive case shows when the rule applies; the near-miss changes one consequential condition and shows when the conclusion fails. Together they teach the boundary of the Websites mechanism better than another unlabelled example.
Ask another reader which devtools panes would verify condition truth and final computed color.
Audit check: retain the source version, units, settings, exclusions and rounding rule. A future correction should be able to alter one field without rebuilding the entire explanation from memory.
Limit: implementation bugs may require a reduced test against the current spec.
CHAPTER 20 OF 20 · Report and continue
20. Continue through verified website routes
Style containment and counter scope concern generated numbering boundaries; container units concern eligible size containers and fallback lengths; cascade layers concern declaration priority. These nearby routes help isolate the stage where a result changed.
Ask what would have to stay fixed for the comparison to be fair. Record those controls explicitly, then name the first uncontrolled condition that could reverse the conclusion. This is the practical transfer step, not an optional footnote.
Build a pipeline: container selection, query evaluation, cascade, computed-value substitution, inheritance, used value. Link each sibling article to its stage.
Communication test: replace any sentence that says two things are “the same” or “different” with a sentence naming the operation, reference condition and supported consequence. The extra words are useful when they let a future reader repeat the decision without access to the original author.
Change one stage at a time in a reduced test and predict the output before refreshing.
Decision check: end with an action or interpretation that follows from the stated conditions, followed by a boundary sentence explaining when a specialist rule, local procedure or additional measurement is needed.
Limit: a pipeline diagram simplifies interactions and should be checked against the full feature specification.
Continue through the verified reading route
Style containment and counter scope
Style containment and counter scope. Use this for counter creation and scope across containment boundaries.
Container query units with no eligible container
Container query units with no eligible container. Use this for size-container selection and computed length fallback.
Cascade layers with important declarations
Cascade layers with important declarations. Use this when a true condition still loses during the cascade.
Frequently asked questions
Does a descendant override change an ancestor style query?
No. The query reads the selected ancestor’s computed value; a descendant override affects that descendant and its subtree.
Are custom properties always inherited?
Unregistered custom properties inherit by default. Registered properties can declare different behaviour.
Can a query be true while its declaration does not win?
Yes. A true query makes declarations eligible, after which the cascade and value validity still apply.
Authoritative sources and further reading
W3C CSS Containment Module Level 3. The specification defines style query containers, container selection and computed-value matching.
W3C CSS Custom Properties Level 1. The specification defines custom-property inheritance, computed values, var() substitution and invalid values.
W3C CSS Properties and Values API Level 1. The specification defines registered custom-property syntax, initial values and inheritance behaviour.
W3C CSS Cascading and Inheritance Level 4. The specification defines cascade and inheritance stages that precede final computed values.
Return to the Websites subject guide, The Gold Standard of Education, or the How X Works hub.