Check CSS custom property scope between selectors

This checker compares the selector that defines a variable with the selector that uses it. It validates both selector strings, handles selector lists, and reports whether every usage branch is structurally covered by at least one definition branch. The result helps you catch a common source of missing design tokens before debugging computed styles in a browser.

Describe the definition and usage points

Enter the selector for the rule that declares the custom property in the definition field, then enter the selector for the rule that calls <code>var()</code> in the usage field. For example, a token defined on <code>.theme-dark .card</code> is available to a usage on <code>.theme-dark .card &gt; .title</code>, because the title is selected beneath the card that receives the declaration. A definition on <code>:root</code> is treated as global because the root element is an ancestor of the document content. Both fields may contain comma-separated selector lists. The checker evaluates each usage branch independently and requires every branch to be covered for the overall answer to be true. It reports which definition branch matched each covered usage branch, making a long list easier to audit. This is a selector relationship check, so you do not need to paste a stylesheet, a declaration block, the property name, or its value. Supplying only the two relevant selectors keeps the result focused on cascade scope rather than unrelated source order or value syntax.

Understand the structural scope decision

The checker models the part of custom property availability that can be determined from selectors alone. It asks whether the definition selector can identify the same element as, or an ancestor of, the element identified by the usage selector. Compound requirements are respected: a definition on <code>.card.featured</code> is not assumed to cover a usage that mentions only <code>.card</code>. Child combinators must remain child combinators, while a descendant relationship may span additional compounds in the usage selector. Selector lists work as alternatives on the definition side and as obligations on the usage side. This deliberately conservative approach avoids claiming that a variable is available when the relationship is not visible in the selector text. Runtime facts can still change the real cascade. Source order, conditional rules, shadow boundaries, inline styles, layers, specificity, explicit resets, and the actual document tree are outside the two-selector input. Treat a true result as confirmation of structural containment, and use browser computed styles when you need to prove the final value in a particular rendered document.

Use validation errors to fix ambiguous input

Each selector is parsed before comparison. Empty selector-list branches, unmatched brackets or parentheses, unfinished combinators, declaration punctuation, incomplete class, ID, or pseudo tokens, and other malformed forms return an input error instead of a guessed result. That distinction matters in automation: false means the supplied selectors are valid but the requested usage is not structurally covered, whereas an error means no scope conclusion was made. Keep the fields as selectors only. Do not include braces, semicolons, a custom property declaration, or an entire CSS rule. Escaped characters, quoted attribute values, attribute selectors, and functional pseudo-classes remain grouped during tokenization so commas and combinators inside them are not mistaken for top-level syntax. The algorithm is deterministic, makes no network request, and has a fixed input-length limit. You can therefore use it in a linting step, a pull-request check, or a design-token migration script and receive the same result for the same pair every time. If advanced relational selectors encode facts that only a live DOM can settle, interpret an uncovered result conservatively and verify it against the target markup.