Foundations
Foundations explain the shared design and implementation rules behind Monster. This section is meant for both developers who integrate components and designers who need to understand the visual system those components are built on.
What This Section Covers
Color
Learn how Monster pairs foreground and background tokens, how dark mode is handled automatically and which color families should be used for states, emphasis and neutral surfaces.
Layout
Understand stack, cluster and split patterns, token-based spacing and why container-aware layouts are the preferred default for embedded examples and complex controls.
Typography
See the heading scale, inline content rules and typographic elements that are safe to use across the system.
Themes
Experiment with theme values and inspect how controls, tables, badges and stateful UI react when token pairs change.
Utilities
Reuse badges, icons and loading indicators consistently instead of rebuilding status affordances in every component example.
For Developers
Build with tokens first
Prefer Monster tokens such as --monster-color-*, --monster-bg-color-*, --monster-space-* and --monster-border-radius before introducing custom CSS values.
Keep examples truthful
Documentation examples should show the same markup, runtime behavior and design constraints that real projects will see. Foundations exist so component pages do not need to re-explain the same styling rules again and again.
For Designers
Design with paired surfaces
Monster does not treat color as isolated swatches. Foreground, background, border and state layers belong together and need to remain legible in both light and dark contexts.
Design within a system, not per screen
The most valuable design decisions here are the reusable ones: spacing rhythm, readable hierarchy, loading feedback, state emphasis and behavior inside narrow containers or split views.
Global Style Layers
The Monster style system contains a number of global layers. Not all of them need their own long-form page, but it helps to know where they belong.
Foundations pages also use a lighter documentation pattern for principles, rules and checklists. Those blocks are intentionally not styled as full cards. Cards remain the right pattern for UI surfaces and grouped content, while documentation rules should stay flatter and easier to scan.
Core tokens
property, theme, color, space, border
Text and content
typography, link, table, badge, icons
Control and layout primitives
control, form, button, display, floating-ui, popper
Behavioral feedback
skeleton, spinner, accessibility, normalize
Shared Principles
Accessibility is not optional
Foundations should hold up when users change font size, rely on keyboard input or switch to dark mode. If a styling decision breaks one of those conditions, it is not a foundation.
System consistency beats one-off styling
The goal is not visual sameness, but predictable reuse. Repeated patterns should become easier over time, not harder.
Examples should reveal real constraints
Split panels, narrow containers, paired colors and state feedback are part of the product reality. The foundations pages should prepare readers for those conditions.
Use this section as the shared language
Designers can reference the system intent, developers can reference the token and implementation rules. That shared vocabulary is the real purpose of this section.