Solid Design System

Solid Design System documentation showing component inventory and token structure

Solid is a design system built on Bootstrap foundations with opinionated conventions for component governance, design tokens, and state management. It is designed for teams that need a shared component library across internal tools, marketing pages, and product interfaces without maintaining separate implementations for each context.

This overview covers the system architecture, how the component inventory is structured, the token layer that drives visual consistency, and the philosophy behind how Solid handles component states. If you are evaluating Solid for a project, this page gives you the structural picture before you start looking at individual components.

System Architecture

Solid is organized into three layers that build on each other. Each layer has a defined responsibility, and changes in one layer propagate predictably to the layers above it.

Token Layer

The token layer is the lowest level of the system. It defines the raw values that every component references: colors, spacing increments, font sizes, border radii, and shadow definitions. Tokens are expressed as CSS custom properties and grouped by category.

  • Color tokens use a semantic naming convention. Instead of--blue-500, Solid defines --solid-color-primary,--solid-color-surface, and --solid-color-danger. This separation means you can change the primary color from blue to indigo by updating a single token, and every component that references it updates automatically.
  • Spacing tokens follow a 4px base scale:--solid-space-1 through --solid-space-16. Components use these tokens for all padding, margins, and gaps. The scale is intentionally constrained to prevent one-off values from creeping into the codebase.
  • Typography tokens define font families, weights, sizes, and line heights. Solid ships with a type scale that covers body text, headings, captions, and monospace code. Each size token includes a paired line height token so you never have to calculate leading manually.

Component Layer

The component layer contains the HTML structure, CSS, and optional JavaScript for each UI element in the system. Components reference tokens exclusively. No component contains hardcoded color values, pixel-based spacing, or font size declarations. This constraint is what makes theming and customization possible without editing component source files.

Each component is self-contained in a single directory that includes its markup template, its styles, and a documentation page that describes its API and usage guidelines. This structure means you can audit, update, or remove a component without affecting anything outside its directory.

Layout Layer

The layout layer provides page-level containers, grid systems, and responsive utilities. It sits above the component layer because layouts compose components into page structures. Solid includes a 12-column grid, a flexbox utility set, and a small collection of pre-built page templates for common layouts: dashboard, documentation, marketing landing page, and settings panel.

Component Inventory Structure

Solid organizes its components into five categories based on their function in an interface. This categorization is not cosmetic. It determines the dependency rules between components and the order in which they are documented.

  • Primitives: Buttons, inputs, labels, badges. These are the atomic elements that cannot be broken down further. Primitives depend only on tokens.
  • Composites: Form groups, card headers, list items with actions. These combine two or more primitives into a reusable pattern. Composites depend on primitives and tokens.
  • Containers: Cards, modals, drawers, accordions. These hold other components and manage visibility or layout. Containers depend on composites, primitives, and tokens.
  • Navigation: Navbars, sidebars, breadcrumbs, pagination. These handle movement between views or sections. Navigation components often depend on containers and primitives.
  • Feedback: Alerts, toasts, progress bars, spinners. These communicate system status to the user. Feedback components are typically standalone and depend only on tokens and primitives.

Dependency rules flow in one direction: higher-category components can depend on lower-category ones, but not the reverse. A card can contain a button, but a button should never import styles from a card. This constraint prevents circular dependencies and keeps component weight predictable.

Token Foundations

The token system in Solid operates at two tiers. Global tokens define the raw palette and scales. Component tokens map global tokens to specific properties within a component.

For example, the global token --solid-color-primary might resolve to#2563eb. The button component then defines --solid-btn-bg: var(--solid-color-primary). If you want to change only the button background without affecting other primary-colored elements, you override the component token. If you want to change the primary color everywhere, you override the global token.

This two-tier approach prevents the common problem where changing a global value has unexpected effects on distant components. It also makes it straightforward to create alternate themes by providing a new set of global token values.

Component State Philosophy

Every interactive component in Solid defines its states explicitly. A button is not just "a button." It is a component with default, hover, focus, active, disabled, and loading states. Each state has documented visual changes and behavioral expectations.

  • Default: The resting appearance when no interaction is occurring
  • Hover: Visual feedback on mouse enter. Touch devices skip this state.
  • Focus: Keyboard navigation indicator. Solid uses a visible focus ring on all interactive elements, not just links.
  • Active: The pressed or engaged state during a click or tap
  • Disabled: Reduced opacity and pointer-events removal. Disabled components are still visible but non-interactive.
  • Loading: A spinner or skeleton replaces the component content while an async operation is in progress

Defining these states upfront means developers do not have to invent hover effects or focus styles on a per-component basis. The system provides them, and overriding them requires an intentional decision with a corresponding token override.

Working with Solid

To start using Solid in a project, see the Getting Started guide for installation and configuration instructions. To explore the component library with live examples, visit the Solid Demo page.

For product details and licensing, see the Solid Design System product page or browse the full design systems catalog.