NebulaKit is a system where components are built from multiple layers. This page shows how those layers fit together at a high level.

Detailed explanations of each layer are covered on the Philosophy page.
Styling engine
The styling engine is a deterministic resolver. It does not think or guess. Components declare intent through data attributes and the engine maps that input directly to output.
All styling is driven by shared CSS tokens. Themes and brands replace token values, not component logic. Dark mode is a palette inversion, not a separate system.
Styling is orthogonal. Theme, brand, color, variant, intent and state resolve independently and combine predictably.
Selectors are flat and constrained. No deep nesting, no specificity wars. Performance is enforced by design.
Drawing mechanism
The drawing mechanism defines how components become visible.
All rendering is handled through the Box component. Box acts as the fundamental drawing surface, similar to a rectangle on a canvas. Every visible part of the system is expressed through it.
There are no alternative rendering paths or special cases. All components ultimately resolve to Box, ensuring a single, unified way to create and control surfaces.
This keeps rendering consistent and predictable. Every surface follows the same rules, uses the same capabilities and behaves the same way across the system.
Responsiveness
Responsiveness is a separate mechanism handled entirely in JavaScript.
It is implemented through React and exposed through the Box component. All responsive behavior flows through this single path, making it centralized and consistent across the system.
Responsive values are resolved at runtime, not through authored media queries. The logic is defined once and reused everywhere, ensuring predictable behavior without duplication or divergence.
Accessibility
Accessibility is enforced through semantic HTML.
Components produce correct semantic structure by default. It is part of their contract, not an optional concern. Elements, roles and attributes are applied intentionally to ensure proper meaning and behavior.
Good defaults are provided, with the ability to adjust semantics when needed. Components aim to follow accessibility standards as closely as possible while keeping usage straightforward.
Composition and inheritance
Component behavior is defined through composition and inheritance.
Components are built by composing smaller building blocks rather than duplicating logic. Functionality is assembled, not rewritten.
Inheritance refers to prop surfaces flowing through composition. Components expose capabilities from their underlying primitives instead of redefining them, keeping APIs consistent and avoiding duplication.