A component has a fallback colour, yet its text still inherits an unexpected colour from its parent. The custom property is present. That is precisely why the fallback may not be used.
The short answer is that an ordinary var() fallback handles an unavailable or guaranteed-invalid custom-property value. It is not a general validator for the property receiving that value. An existing token can be acceptable as an unregistered custom property and unsuitable as a colour, width or other destination value.
This article follows original colour, width, alias and cycle examples through substitution and defaulting. The examples assume current support for ordinary CSS custom properties and isolate registration as a separate case. Start with the Websites subject guide for the wider question of dependable, understandable pages.
eduKateSG · Websites
Find your next learning step
Follow availability, substitution, destination validity, inheritance and rendered results as separate checks.
ROUTE 1 · CHAPTERS 1–5
Separate the failure stages
Build the first-principles model and follow the central original example.
ROUTE 2 · CHAPTERS 6–10
Follow the available token
Change one condition and preserve the accounting at each step.
ROUTE 3 · CHAPTERS 11–15
Trace dependencies
Include the additional inputs that alter a real component.
ROUTE 4 · CHAPTERS 16–19
Investigate and transfer
Test predictions and identify the limits of the simplified model.
ROUTE 5 · CHAPTERS 20–23
Check and continue
Use independent checks, useful questions and verified onward routes.
Chapter contents
Separate the failure stages · Chapters 1–5
2. Understand the deliberately broad token container
3. Work the missing-value case first
Follow the available token · Chapters 6–10
6. Repeat the reasoning with a non-inherited property
7. Build a case table with meaningful labels
8. Follow inheritance before declaring a token missing
Trace dependencies · Chapters 11–15
11. Respect commas and empty fallback syntax
12. Do not append units as if substitution pasted text
13. Recognise dependency cycles
14. Separate the token's importance from its substituted content
Investigate and transfer · Chapters 16–19
16. Keep runtime updates inside the same model
17. Investigate the actual computed dependency
Check and continue · Chapters 20–23
20. Compare two repairs that look similar on screen
21. Preserve evidence when a token is supplied from configuration
When a variable-based declaration fails, there are several different candidates for the word value. There is the text stored in the custom property, the result after its references are substituted, the destination property’s computed value and the size or colour eventually used for rendering. A diagnosis becomes clearer when it identifies the stage being discussed.
Our central example uses –tone as an unregistered custom property and color as the destination property. The name –tone suggests a colour to a human reader, but the name does not impose a colour type. A token such as 20px can be a valid unregistered custom-property value while being unsuitable for color.
Imagine a fictional notice component whose parent has navy text. Its own stylesheet supplies color: var(–tone, crimson). If –tone is unavailable, crimson can be substituted. If –tone contains 20px, substitution produces a different situation. The browser has a value to substitute, but color: 20px is not an acceptable final colour declaration.
Before changing code, write down both questions: can var() obtain the referenced value, and can the destination property use the substituted result? These questions are related but distinct. A fallback designed for the first question should not be described as if it promises to solve every failure at the second.
CHAPTER 2 OF 23 · Separate the failure stages
2. Understand the deliberately broad token container
An unregistered custom property holds a permissive CSS token sequence, subject to the syntax’s restrictions. It is not an arbitrary text macro pasted into the stylesheet before parsing. Its broad acceptance allows the same mechanism to carry lengths, colours, lists and other fragments, while leaving the receiving property responsible for its own grammar.
This flexibility is useful when a component needs to reuse a spacing value or a theme colour across several declarations. It also makes the naming agreement important. Calling a property –notice-color helps maintainers understand its intended role, but does not itself prevent another rule from assigning a length or a list of tokens to it.
Consider three assignments in a disposable exercise: –tone: seagreen, –tone: 20px and –tone: seagreen solid. Each is a different token sequence. The question whether a consuming color declaration can use it must be asked separately. A sequence that works for a border shorthand may be inappropriate for a single colour property.
The W3C custom-properties specification defines the substitution mechanism and invalid-variable behaviour. Our named tokens and cases are original teaching choices. Keep an inventory of intended token roles when building a real component, and inspect the actual computed custom property instead of assuming a friendly name guarantees a suitable value.
Set the parent’s color to navy and give the child color: var(–tone, crimson). In the first exercise, do not define –tone on the child or its ancestors. With no usable referenced value, the fallback supplies crimson. The child becomes crimson under these controlled conditions, establishing what the fallback is actually capable of doing.
Now define –tone: seagreen on the child. The reference can use that value, so the child becomes seagreen. The crimson fallback is present in the declaration but is not the selected substitution. Its mere appearance in the source does not mean it participates in every later value decision.
Return to the missing case and change the fallback to darkorange. The child should now become darkorange, again assuming no higher-priority declaration changes the question. This is a useful small test because it isolates the fallback path without simultaneously introducing bad destination syntax, competing rules or inherited token definitions.
Record the conditions alongside the result: unregistered –tone unavailable at the child; consuming color declaration wins; valid crimson fallback. If a real page behaves differently, inspect those conditions. Perhaps an ancestor defines –tone, perhaps another color declaration wins, or perhaps the value is registered with an initial value. The isolated experiment gives you a comparison, not permission to skip the actual page state.
CHAPTER 4 OF 23 · Separate the failure stages
4. Change the existing value to the wrong kind
Keep the parent’s navy colour and the child’s color: var(–tone, crimson), but set –tone: 20px on the child. The custom property now exists with a token sequence that can be substituted. The fallback is not selected just because that sequence will be unsuitable for the destination property.
After substitution, the consuming declaration cannot supply a valid color value. In this case, color is inherited, so the child receives its parent’s computed colour, navy. The result is not crimson. It is also not evidence that 20px has somehow become a colour; the destination declaration has failed at a later processing stage.
Compare three labelled cases rather than repeatedly editing one unnamed state. Missing –tone produces crimson; –tone: seagreen produces seagreen; –tone: 20px leads to the inherited navy in our setup. The third case differs from the first even though both may be casually described as a bad variable by someone reading the screen.
This is the central misconception to repair. A var() fallback is not a type-directed try-another-value operator for the receiving property. When a token is present, a destination mismatch can occur after substitution. To explain the observed result, identify the destination property’s defaulting behaviour as well as the availability of the referenced custom property.
CHAPTER 5 OF 23 · Separate the failure stages
5. Do not expect an earlier declaration to return
Suppose the child’s declaration block first says color: orange and then color: var(–tone, crimson). Keep –tone: 20px and the navy parent. It is tempting to expect orange to return when the later variable-based declaration becomes unsuitable. That expectation confuses an early syntax rejection with a failure discovered after the cascade.
The variable-based declaration can participate in the cascade because its eventual substituted value is not yet known in the ordinary way. Once it wins and later proves invalid at computed-value time, the browser does not simply run the cascade again to pick the earlier orange declaration. In our inherited-colour example, the result is navy.
Contrast that with a plainly invalid ordinary declaration written directly as color: 20px after color: orange. The invalid ordinary declaration is rejected for the property, leaving orange available in this simple block. The two pieces of code can contain the same unsuitable length token and still fail at different stages, with different consequences.
For a learner, write the two cases side by side and explain why their results differ. The important distinction is when the browser can establish that the value is unsuitable. A fallback declaration written earlier is a familiar compatibility technique, but it must not be treated as an automatic rescue path for every later invalid substitution.
CHAPTER 6 OF 23 · Follow the available token
6. Repeat the reasoning with a non-inherited property
Colour makes inheritance visible, but it can hide the difference between invalidity and inheritance if the parent colour is unnoticed. Use width for a second experiment. Place a normal block inside a 240px-wide containing block, with no padding, border or margins on the child and no layout features that change ordinary block sizing.
Give the child width: var(–measure, 60px). If –measure is missing, the fallback supplies 60px. If –measure is 90px, the width becomes 90px. If –measure is tomato, substitution yields an unsuitable width value. Width does not ordinarily inherit, so its initial auto behaviour applies in this setup.
For this simple block, auto width fills the available 240px content width. That measured result is an outcome of the stipulated layout, not the definition of invalidity. In another formatting context, auto can lead to a different used size. Avoid writing a universal rule that a failed width variable always becomes 240px or always becomes the parent’s width.
The changed context tests genuine understanding. The same substitution failure that led to inherited navy for color leads to auto behaviour for width. The fallback mechanism did not change; the destination property’s defaulting and layout did. Keep the specified, computed and used quantities separate when reporting a browser measurement.
CHAPTER 7 OF 23 · Follow the available token
7. Build a case table with meaningful labels
A table is useful when each row preserves the conditions that matter. Our width exercise fixes the containing block at 240px and keeps the child free of padding, border and margins. It also assumes the variable-based width declaration is the winning candidate and –measure is unregistered. These are part of the example, not incidental decorations.
| Value available as –measure | Substitution path | Result in the stipulated block |
|---|---|---|
| Unavailable | Use 60px fallback | 60px width |
| 90px | Use the supplied length | 90px width |
| tomato | Supplied token is unsuitable for width | Auto sizing; 240px here |
| 0 | Use valid unitless zero | Zero content width |
The zero row is especially helpful. A value should not be rejected merely because an application author informally treats zero as false. CSS value processing is not JavaScript truthiness. Unitless zero is valid for the width length in this example, so there is no reason to select the 60px fallback simply because the numerical value is zero.
Ask another learner to add a fifth row with a valid percentage and name its reference quantity. A percentage width introduces a containing-block dependency rather than a fallback failure. Then ask for an unsuitable token that produces auto behaviour. The table becomes an exercise in classification instead of a collection of memorised screen sizes.
CHAPTER 8 OF 23 · Follow the available token
8. Follow inheritance before declaring a token missing
Ordinary unregistered custom properties inherit. If the child has no local –tone declaration but its parent defines –tone: seagreen, the child can receive that computed custom-property value. The var(–tone, crimson) fallback is therefore not selected merely because a search of the child’s own rule block finds no definition.
Draw the relevant ancestor chain and inspect where the custom property is supplied. The nearest applicable inherited value can matter more than a global theme file you happened to open first. A local component may also override the custom property, so the value available at the child must be established from its actual cascade and inheritance.
This explains a practical debugging pattern. A component works in isolation, where a token is missing and the fallback is used, but changes when embedded in a larger page that supplies the same token name. The fallback has not stopped working. The referenced value is no longer unavailable in the embedded context.
Choose names that communicate a suitable ownership boundary, and test both isolated and embedded uses. A distinctive component token can reduce accidental coupling, but naming is a convention rather than a technical guarantee of valid destination syntax. The evidence remains the computed token available at the consuming element and the property that receives it.
Consider a parent that defines –base: 10px and –edge: var(–base). The child overrides –base: 30px and uses padding-left: var(–edge). A learner may imagine –edge as a formula that will be reevaluated against the child’s –base. That is not how this ordinary inherited alias behaves.
The parent’s –edge is computed using the parent’s –base, giving 10px. The child inherits that computed –edge value. Overriding –base on the child does not retroactively change the parent’s already computed alias. Under the stated conditions, the child’s padding-left is 10px, even though its own –base is 30px.
If the child also declares –edge: var(–base), the alias is now computed at the child and can resolve to 30px. This changed declaration is a different dependency placement. The example is about the element at which a reference is resolved, not a claim that aliases never respond to changes anywhere in the document.
Use a small dependency sketch with parent and child labelled separately. Write each computed token beside its element before applying the consuming declaration. This makes the point concrete and avoids treating CSS variables as global functions that look up all their inputs afresh wherever a descendant happens to use an inherited result.
CHAPTER 10 OF 23 · Follow the available token
10. Keep nested fallbacks attached to their own question
An expression such as var(–primary, var(–secondary, 12px)) creates a sequence of availability choices. If –primary is unavailable, the nested reference can try –secondary. If both are unavailable, 12px can be used. The nesting does not add automatic destination-type validation to either existing token.
For an original width exercise, let –primary be missing and –secondary be 44px. The width receives 44px. Remove –secondary as well and the result becomes 12px. Now set –primary: tomato while keeping –secondary: 44px. The existing primary token is selected, and the width declaration encounters the unsuitable substituted value.
The browser does not reject tomato as a width and then proceed to the secondary length. The fallback chain answers whether each referenced custom-property value is available under its rules. It is not a list of alternative destination values ranked by eventual success. This distinction remains even when the nesting visually resembles a programming-language recovery expression.
Predict the three results before testing, and describe the chosen branch explicitly. If the explanation says the browser tries 44px because tomato is not a length, it has silently invented a validation step. The repair is to separate the custom property’s available token from the receiving width property’s grammar, just as in the simpler single-fallback case.
The first comma in var() separates the custom-property name from its fallback. The fallback can itself contain commas, as in a font-family list. Reading every comma as a new fallback option would misparse the expression and produce the wrong model of what the browser receives.
For a fictional font token, var(–reading-font, Georgia, serif) uses Georgia, serif as one fallback token sequence when –reading-font is unavailable. It does not mean try Georgia only after checking whether a supplied font token produced the desired visual result. Font matching has its own further behaviour after the value is supplied.
An empty fallback can also be intentional: var(–optional-fragment,) can substitute nothing when its reference is unavailable. Whether the resulting whole declaration is valid depends on the destination grammar and surrounding tokens. Empty substitution is not a universal no-op, because removing a required piece can make the receiving value unsuitable.
Do a paper parsing exercise before testing the rendering. Identify the reference name, the fallback boundary and the complete fallback sequence. Then substitute into the whole destination value and ask whether that resulting value is acceptable. This two-pass method is slower than guessing from punctuation, but it explains both successful optional fragments and unexpectedly invalid combinations.
CHAPTER 12 OF 23 · Trace dependencies
12. Do not append units as if substitution pasted text
Suppose –count contains the number 12. Writing a width value that looks like var(–count)px does not turn the separate tokens into the dimension 12px through simple character concatenation. CSS custom-property substitution works with tokens, so the apparent suffix is not a general unit-construction technique.
An appropriate calculation can instead express the intended dimensional relationship, for example calc(var(–count) * 1px), when the referenced value and property grammar make that expression valid. Alternatively, store the complete length 12px in a token whose intended role is a length. The choice should match how the component plans to use the value.
Test the distinction with a number token and a length token under separate names. For a width needing a length, identify which expression supplies a length after substitution. Then change the number token to an unsuitable word and predict the failure path. A fallback remains an availability mechanism; it does not make arbitrary multiplication operands valid.
The transferable habit is dimensional reasoning. Ask whether an input is a number, a length, a percentage or a compound sequence, and how the receiving expression combines it. A browser can reject an expression that looks readable in ordinary prose because its token structure and value grammar do not describe the quantity the property requires.
Custom properties can reference one another, so a token system can contain a cycle. Consider –a: var(–b) and –b: var(–a) on the same element. Neither has an independent value from which resolution can finish. In the unregistered case under discussion, the cycle makes the affected custom-property values unusable for ordinary substitution.
Now let width be var(–a, 40px). With the cyclic –a unavailable in the required sense, the consuming fallback can supply 40px. This differs from a usable –a containing tomato, which would be substituted and then fail the destination width grammar. The visible result can therefore distinguish two kinds of problem that were both called invalid.
Do not assume that adding fallbacks inside the cyclic definitions automatically removes the dependency. The specification’s dependency analysis includes relevant references in fallback arguments. A reliable repair gives the dependency graph a genuine independent base or removes the unintended cycle, rather than adding more nested references without examining their relationships.
For a learner, draw arrows from each defined token to the tokens its value references on that element. Mark a route that returns to its starting point. Then propose a changed graph with –b: 18px. The revised –a can resolve to 18px. The exercise tests whether the repair changes the dependency structure, rather than merely making the declaration longer.
CHAPTER 14 OF 23 · Trace dependencies
14. Separate the token's importance from its substituted content
An important annotation on a custom-property declaration affects which declaration supplies that custom property’s value. It does not become a portable importance flag that automatically makes every consuming property important. Token selection and destination-property competition are separate cascade questions.
For an original example, an important –tone: seagreen can determine the available –tone against a competing normal –tone declaration. A normal color: var(–tone) still remains a normal color declaration. A competing important color declaration can defeat it. The importance attached to the token definition has not travelled through var() into the consumer.
This is another reason to keep two ledgers. First determine the custom property available at the consuming element. Then determine which destination declaration wins, and only then follow the appropriate substitution and value processing. Combining both ledgers into a slogan such as the variable is important conceals where the actual priority decision occurs.
When a component does not change colour after a token update, check whether its consuming declaration wins at all. The token may be valid and available while another color rule controls the element. In that case, changing fallbacks addresses the wrong mechanism. A useful diagnosis establishes both the supplying token and the winning destination declaration before explaining the rendered result.
CHAPTER 15 OF 23 · Trace dependencies
15. Treat registered properties as a different contract
Registration can give a custom property an explicit syntax, inheritance behaviour and initial value. That changes the contract. A registered length property is not simply the unregistered permissive token container used in our central colour example. An explanation must say whether registration is present and valid in the tested browser.
Imagine –panel-size registered with length syntax, inherits set to false and an initial value of 24px. A consuming width: var(–panel-size, 60px) can receive the registered initial value even when no ordinary local declaration supplies a suitable length. The 60px fallback is not automatically the missing-value result that it was for an unregistered property.
If a supplied value cannot meet the registered syntax, its processing follows the registered-property rules, including the specified defaulting behaviour. In this deliberately non-inheriting example, the initial 24px is the useful expected result. Do not describe this as var() examining width and deciding that 60px looks safer.
The W3C Properties and Values API specification defines the registration model. Registration can make a token interface clearer, but it does not prove that the chosen value produces a usable layout. Confirm the registration’s syntax, initial value and inheritance setting, then test the actual component under the support requirements of the project.
CHAPTER 16 OF 23 · Investigate and transfer
16. Keep runtime updates inside the same model
Script or a user-selected theme can change a custom property while the page is open. The update does not create a new fallback rule. If an unregistered colour token changes from seagreen to 20px, the same availability-versus-destination distinction applies when styles are recomputed.
For a controlled experiment, begin with a valid seagreen token and observe the computed text colour. Change only the token to a length and inspect both the available custom property and the resulting color. Restore the valid colour afterwards. This sequence is more informative than changing several theme settings and assuming the last visible colour identifies the failure mechanism.
Keep application-side validation separate from CSS fallback semantics. A theme editor can deliberately restrict inputs to supported colour values before writing them to the page. That is an application contract, not a new promise made by var(). If imported configuration or another stylesheet can supply values, include those paths in the test.
Describe a successful check narrowly. It may establish that the particular input route rejects unsuitable values and that the tested component uses the accepted colour correctly. It does not establish that every future token assignment from every source is safe or suitable. The useful evidence connects the input, available token, consuming property and observed result.
CHAPTER 17 OF 23 · Investigate and transfer
17. Investigate the actual computed dependency
Start by selecting the exact element and identifying the destination property. Confirm which declaration wins. Then inspect the custom property available at that element, including inherited definitions and registration. Finally inspect the destination’s computed result and the layout conditions that turn it into a rendered size or colour.
MDN's custom-property guide is a practical companion for these distinctions. Browser developer tools can expose inherited rules and computed values, but interfaces vary. Learn which evidence answers your question rather than rely on the colour of a particular crossed-out line in one version of a tool.
Write a diagnosis in stages: the child’s –measure is tomato; the winning width declaration references it with a 60px fallback; substitution uses the existing token; the resulting width is unsuitable; ordinary auto sizing produces the measured width in this specified block. Each stage is inspectable, and a disagreement tells you where to investigate next.
Avoid beginning with the final screenshot alone. Two different failure paths can produce similar sizes, while the same invalid destination can produce different used sizes in different formatting contexts. A useful investigation preserves the declaration, dependency and property semantics that explain the observation rather than infer all of them from the apparent shape of a rectangle.
CHAPTER 18 OF 23 · Investigate and transfer
18. Test the edges of the token interface
A useful component test includes a valid value, an unavailable token, an unsuitable existing token and a context that supplies an inherited value. These cases exercise different paths. They are more informative than several valid colours that all follow the same successful substitution branch.
Add one dependency case when aliases are part of the design. Does an alias resolve on the ancestor or locally? Add a cycle case if configuration can create references among tokens. If registration is used, test its actual initial value and inheritance behaviour separately. Name each test by the distinction it is meant to establish.
Choose assertions that match the intended quantity. For the 240px block exercise, a rendered width assertion is meaningful because the box model and containing block are fixed. For a general component, checking that a token exists is not enough to prove a readable result, and checking a final width alone may not explain why the expected fallback was unused.
Preserve a minimal failing example before repairing a production stylesheet. Remove unrelated selectors and scripts while retaining the mechanism. Once the explanation predicts that example correctly, apply the scoped repair and check the real user task. A token-system improvement should make the intended component dependable, not merely produce a passing demonstration detached from its actual use.
An original exercise uses a parent with color: darkslateblue and –accent: 18px. Its child declares color: orange followed by color: var(–accent, teal). Assume no competing declarations and no registration. Predict the child colour, then explain why both orange and teal fail to become the answer.
The answer is inherited darkslateblue. The existing –accent token is substituted, so teal is not selected. The later variable-based declaration wins before its unsuitable result is discovered, so the earlier orange declaration is not recovered through a fresh cascade. Because color inherits, the parent’s computed colour supplies the result in this setup.
Now remove the parent’s –accent definition. The child becomes teal. Next define –accent: olive locally on the child. It becomes olive. Finally move the same consumption pattern to width in an ordinary block: the invalid-existing-token case leads to width’s own defaulting and layout behaviour, rather than inheritance of the parent’s colour.
Ask the learner to invent one additional case and state its assumptions before checking. A strong example changes the mechanism, perhaps by introducing an inherited alias or a registered initial value. Merely replacing olive with another valid colour tests vocabulary more than understanding of the fallback boundary.
CHAPTER 20 OF 23 · Check and continue
20. Compare two repairs that look similar on screen
Return to the navy parent and the child whose –tone contains 20px. One proposed repair removes the unsuitable local custom-property declaration. Another changes it to –tone: crimson. If no ancestor supplies –tone, both can make the child’s text crimson in our example. The identical screen colour conceals two different contracts.
After the removal, the child uses the fallback because the reference is unavailable. After the replacement, it uses an existing crimson token and does not need the fallback. Add an ancestor definition –tone: seagreen and repeat. The removal version can inherit seagreen, while the explicit local crimson version remains crimson under these controlled conditions.
That changed-context test helps a team decide which repair matches its intention. Should the component participate in an inherited theme, or should this particular instance set a local colour? The browser cannot infer that product decision from the fact that both versions happened to look crimson in the isolated demonstration.
Write the expected inheritance behaviour into the component’s usage notes and test it. A repair is more dependable when the intended source of the value is explicit. Removing an unsuitable declaration can be appropriate, but calling it equivalent to assigning a suitable local token would ignore the surrounding context in which the component will be reused.
CHAPTER 21 OF 23 · Check and continue
21. Preserve evidence when a token is supplied from configuration
Suppose an original teaching configuration contains the key noticeTone with the string 20px. An application copies it into –tone. The CSS result can be explained by the same substitution model, but the source of the mistake now lies upstream. A stylesheet-only patch may conceal the problem while other consumers receive the same unsuitable value.
Record the supplied configuration, the written custom property and the consuming declaration separately. If the application promises that noticeTone is a colour, validate that promise at the relevant input boundary. Keep the rejection or correction understandable to the person configuring the theme, and preserve an appropriate default for that application path.
Then test a suitable colour, an unavailable setting and an unsuitable setting through the actual input route. The exercise should show whether the application contract holds before the value reaches CSS. This complements the browser lesson: CSS fallback semantics remain the same, while the application can choose a stricter, documented interface for the values it supplies.
Why did the fallback not run when my token was wrong? The relevant question is wrong for which stage. An existing unregistered token can be available for substitution and still be unsuitable for the receiving property. The ordinary var() fallback does not validate every substituted value against that destination’s grammar.
Why did an earlier ordinary declaration not return? A declaration that becomes invalid at computed-value time is not handled by simply rerunning the cascade to choose a previous candidate. Identify the destination property’s defaulting behaviour. This differs from an ordinary invalid declaration that can be rejected before that later stage.
Does an undefined local token always trigger fallback? No. An unregistered custom property may be inherited from an ancestor. A registered property can also have an initial value and a different inheritance contract. Inspect the value available at the consuming element rather than only the nearest rule block you wrote.
Can a fallback guarantee a usable design? No. Even a valid substituted value can be inappropriate for the reader’s situation. A valid width can clip content, and a valid colour can be unreadable against its background. Value validity, layout behaviour and user accessibility require related but distinct checks.
Style priority and token values
Resolving Cascade Layers When Important Declarations Reverse Priority.
Space and visual sequence
Tracing Dense Grid Placement Without Confusing Visual and Document Order · Redistributing Flex Shrink When Items Reach Their Minimum Sizes.
For a connected overview, return to Websites. For how values become geometry and pixels, read Web Browsers, Layout Geometry, Pixels and Rendering. For the reader’s complete task, continue with Web Accessibility and Digital Accessibility Testing Services.
Primary sources checked on 27 October 2026: W3C custom properties and substitution, W3C registration model and MDN's custom-property guide. The notice, block, alias and dependency cases are original teaching constructions. A real project should also verify its actual browser support and component requirements.
Continue through How X Works and Learning That Transfers into Life by explaining an unfamiliar failure in stages. Identify what is available, what wins, what is substituted and what the destination can use. That explanation turns a fallback from a hopeful extra value into a tool with a clear, testable job.