Chapter 4
Local theme inheritance
Reader content uses the Dark surface without a separate Dark reader implementation.
FG UI 1.3 development
Component Inheritance 1.3
Phase 2 stress coverage for ordinary FGUI components inside local Light and Dark theme surfaces.
SEMANTIC INHERITANCE AUDIT
These specimens intentionally reuse the normal component contracts. The local theme surface changes semantic tokens; components should not need Dark-specific copies.
Buttons and actions
Brand actions stay FG blue while secondary, soft, ghost and icon actions inherit readable local ink and surfaces.
Forced Light
Forced Dark
Forms and selectors
Controls inherit local surfaces, borders, placeholder ink and native color-scheme.
Cards, status and navigation
Common accents use semantic accent ink rather than fixed dark-blue foregrounds.
Dark surface
Card and status
Links, labels and statuses stay readable inside a local Dark region.
Data, alerts and lists
Borders, rows, notes and semantic states inherit from the containing surface.
Information
Semantic information state on a local Dark surface.
Reusable note with a link.
| Name | Status |
|---|---|
| Theme inheritance | Pass |
| Local tokens | Active |
- Semantic surface
- Semantic border
- Semantic text
Reader and maintenance
1.2 families must inherit the same local theme rules as the older component catalogue.
Asset integrity
Check the package manifest inside a local Dark surface.
FG UI Theme Packv1.0.0
InstalledALT family inheritance
ALT remains an alternative FGUI presentation, not a separate colour system.
ALT information
The presentation differs; the theme contract does not.
Nested restoration
A nested Light surface must restore Light controls even inside a Dark parent.
Dark parent
Nested Light child
Phase 3 boundary: overlays physically reparented to document root (for example custom-select panels, menus, tooltips and modal portals) need formal theme-context transfer. Their trigger surfaces are covered here; portal transfer is deliberately the next roadmap phase.