Brickv0.1.2
Brand through meaning

Theming

Map your visual identity onto Brick's semantic CSS contract without replacing component recipes.

One semantic pipeline

Change the brand, keep the component contract

Your brand choices map to semantic roles. Every Brick component consumes those roles without needing a new recipe.

Brand choicesTypeShape
Semantic rolesaccent-solidsurface-canvastext-primaryradius-control
Stable output

Project ready

Same anatomy, your visual language.

Ready to publish

CSS-first by design

Brick ships complete light and dark defaults. A theme changes semantic values such as accent, surface, text, radius, and motion; components keep the same anatomy and behavior.

css
[data-brick-theme="studio"] {
  --brick-color-accent-solid: #6d4aff;
  --brick-color-accent-on-solid: #ffffff;
  --brick-color-surface-canvas: #fbfaf8;
  --brick-radius-control: 0.625rem;
}

Apply the theme at the document root for the whole product or on a subtree when one region needs a different visual expression.

One theme contract, two delivery modes

Themes work identically with the complete stylesheet and the optional modular path. styles.css already contains tokens, foundations, and every component recipe. In a measured route-aware build, styles/core.css supplies the same tokens and foundations once while files such as styles/button.css and styles/card.css supply selected component recipes.

Do not import tokens.css beside either complete or modular component styles. Changing CSS delivery must never change semantic token names, appearance behavior, or the visual contract a theme overrides.

html
<html data-brick-theme="studio">
  <body><!-- every Brick component now consumes Studio roles --></body>
</html>

Appearance is one theme dimension

Brick follows the operating-system preference by default. Set data-brick-appearance="light" or "dark" on the document or a subtree when your application owns an explicit choice.

No required provider

Brick does not require React context, runtime palette generation, local-storage policy, or render-time style injection. Applications may coordinate a persisted preference before paint, but the component package remains static CSS.

Override paired roles together

When changing a surface or strong accent, update its foreground partner and validate interaction states. Theme generation is not proof of accessible assignment; contrast and state ordering still need evidence.

Use this short review before shipping a theme:

  • check resting, hover, pressed, focus, disabled, and invalid states;
  • review both light and dark appearance;
  • zoom narrow layouts and verify Forced Colors; and
  • keep semantic role names in component code instead of raw brand colors.

Continue with the catalog

See these principles expressed through real component APIs and examples.Browse components