Core Concept

Why Lemmo UI completely decouples component geometry, logic, and accessibility from cosmetic themes.

The Headless Container Model

Most traditional UI libraries hardcode colors or lock developers into a single visual style. If you want a neon look today, you write classes for that; if you want a clean minimalist SaaS theme tomorrow, you rewrite component styles across the entire application.

Lemmo UI operates like a container: The component library defines the permanent skeleton (spacing, layout flex/grid, accessibility, ARIA roles, and state interactions). Visual themes are pluggable CSS skins that attach to an abstract token contract.

Skeleton vs. Skin

Library Core (Skeleton)

Permanent

Geometry & Layout: Flexbox, CSS grid, padding, min-heights, gap rhythm.

Accessibility (a11y): ARIA attributes, keyboard traps, focus rings, disabled states.

Token Contract: Consumes abstract CSS variables (var(--primary), var(--card)).

Theme (Skin)

Swappable

Palettes: Background canvas, card surface, brand action lime, accent pink.

Border Radii: Proportional scaling from sharp 0px up to rounded 12px.

Elevation & Glow: Lemmo brand inset gloss, breathe glows, ambient drops.

The Pure Token Rule

To maintain 100% theme independence, all components follow one strict rule:

Guiding Architecture Law

No component file may ever contain hardcoded hex values (e.g. #D1FE17) or rigid utility classes (e.g. bg-black). Colors must always be expressed as paired semantic tokens (bg-primary text-primary-foreground).

Monorepo Strategy

Lemmo UI is published as the package lemmoui. In our project architecture, the frontend app contains zero local UI components or styling overrides — it simply installs lemmoui and imports whichever theme is desired.