In a design system, how should a scoped sub-theme work when one region of a screen, such as an opposing faction's match panel, uses a different theme?
answer
- nearest scope decides
- remap semantic values, not components
- override a coherent set
- overlays can escape the region
- check contrast inside each scope
basics
~20 sA sub-theme remaps the semantic values for one subtree, so components inside it change without knowing why. It must override a coherent set of values, carry its scope into overlays opened from inside, and pass contrast checks on its own surfaces.
solid answer
~40 sA scoped sub-theme marks one region as using a different active value set; components inside keep referencing the same semantic names and resolve them against the nearest themed scope, so the match panel looks like the opposing faction while its buttons and text are the same components. The sub-theme should override a **coherent** set, such as surface, text and accent together, so text never lands on an unexpected background, and each scope needs its own contrast checks: WCAG 2.2 criterion 1.4.3 asks 4.5:1 for normal text at AA, and 1.4.11 asks 3:1 for non-text parts. Menus, popovers and sheets opened from inside the panel often render outside it, so they must receive the panel's scope explicitly. Keep nesting shallow and make the region's edge visibly contained.
go deeper
Recall that components inside a sub-theme are unchanged; the region supplies different values for the same semantic names.
Explain nearest-scope resolution, why overrides must come in coherent groups, and what contrast checks each scope needs.
Anticipate the leaks: overlays at the root, toasts, cached content and baked-color images, and make the shared components handle them.
Decide how much sub-theming the system permits, which groups, how deep, and whether the test matrix it creates is worth the product value.
## What a scoped sub-theme is In a design system with runtime theming, the app has an **active theme** at its root. A **scoped sub-theme** marks one region, such as a panel, a card or a section, as using a different value set for everything inside it. Components inside keep asking for the same **semantic tokens** (surface, text-primary, accent, border) and get the region's answers instead of the app's. In a multiplayer game's companion app, a player in the blue faction might open a match summary where the opposing red faction's panel is shown in red's theme, while the rest of the screen stays blue. The design goal is that **components never know** they are inside a sub-theme; the scope does the work. ## How resolution works When a component asks for a semantic value, the system looks for it in the **nearest themed scope** above it, then the next one out, up to the app root. The exact mechanism is platform plumbing; the design-system decision is what a sub-theme is allowed to override and how its edges behave. ## Rules for a sound sub-theme - **Override a coherent set.** Changing the accent but not the surface, or the surface but not the text, risks text on a background it was never checked against. Sub-themes should override complete groups (surface with its on-surface text, accent with its on-accent text). - **Inherit the rest deliberately.** Anything the sub-theme does not override comes from the outer theme, so the system should document which groups a sub-theme may override and which it always inherits, such as spacing and typography. - **Check contrast inside each scope.** A sub-theme is a new set of pairings. Under WCAG 2.2, criterion **1.4.3 Contrast (Minimum)**, level AA, asks at least **4.5:1** for normal text (3:1 for large text), and **1.4.11 Non-text Contrast**, level AA, asks **3:1** for user-interface components and meaningful graphics against adjacent colors. Each scope, and each place a scope meets its parent, needs those checks. - **Make the edge visible.** A sub-themed region should read as a contained surface, with its own background or border, so the switch looks intentional rather than like a rendering glitch. - **Keep nesting shallow.** A sub-theme inside a sub-theme inside a sub-theme is legal but hard to reason about and to test; most systems document a limit or discourage more than one level. ## Where scopes leak | Situation | Risk | Remedy | |---|---|---| | Menu or popover opened from inside the panel | on many platforms it renders at the root, outside the scope, so it shows the app theme | pass the panel's scope to the overlay explicitly | | Toast triggered from inside the panel | appears in the app's shared area | decide which theme toasts use and document it | | Content moved between regions | keeps the look of its old scope if cached | resolve on placement, not on creation | | Images and icons with baked colors | ignore the scope entirely | use icons that take their color from semantic values | The overlay row is the one teams hit first: a dropdown inside the red panel opens in blue because the overlay layer lives at the root. ## A worked sequence 1. Decide which value groups a sub-theme may override for this panel: surface, text and accent. 2. Mark the panel as a red-faction scope. 3. Verify every component inside uses only semantic values, so nothing needs editing. 4. Make overlays opened from the panel inherit its scope. 5. Run contrast checks and visual tests for the panel in both factions and inside both outer themes. ## What this question is testing Interviewers want to hear that sub-theming is a property of **scope**, not of components; that it needs rules about completeness and edges; and that overlays and contrast are where it breaks in practice.
- A dropdown inside the red-faction panel opens in the blue app theme. Why, and what is the fix?On many platforms and component libraries, overlays render in a layer attached near the app root so they can sit above everything, which places them outside the panel's scope. The fix is to pass the panel's active theme to the overlay explicitly, and to make that the shared overlay component's default behaviour.
- Why not let a sub-theme override any token it likes?Unrestricted overrides create pairings nobody checked, such as a new surface under old text, and make the region's look depend on which outer theme it sits in. Limiting sub-themes to coherent groups keeps contrast verifiable and the result predictable in any placement.
saying these in an interview costs you the question
- Components inside a sub-theme need a special themed variant.
- A sub-theme only needs to change the accent color.
- Overlays opened inside a region always inherit its theme.
- Contrast checked in the main theme covers every sub-theme.
- Deeply nested sub-themes are free and need no extra testing.