Colors

Color in 42UI is orthogonal to variant. The same twelve palettes flow through every accented component, the same six CSS slots underneath. Pick the shape with variant and the palette with color — they compose without knowing about each other.

• variant — filled · light · outline · subtle (owned by cva)
• color — brand · gray · neutral · red · orange · yellow · green · teal · cyan · blue · purple · pink (owned by data-color on the root)

data-color is the entire interop surface. Resolve a palette at the CSS layer once, and every variant in every component picks it up — including dark mode and consumer-defined palettes.

import { Button } from '@42/ui-react/button';

<Button variant="filled" color="brand">Primary</Button>
<Button variant="light"  color="red">Destructive</Button>
<Button variant="subtle" color="gray">Quiet</Button>

Palette

Twelve colors, a few roles. brand is the default accent and gray is the neutral accent — still a mid-tone fill through the same --c-* slots, just colorless. neutral is a distinct palette entry, not a synonym for gray: a fixed white fill + navy text, the same in light or dark theme, matching the kit's own chrome (Button's zero-config default). It goes through the same slot mechanism as every other color — it just resolves to constant values instead of theme-swapped ones. The other nine carry semantic weight by convention (red for destructive, green for success, yellow for warning, blue for InfoIcon) but the kit doesn't lock you in — pick whatever reads right for the component.

Slot variables

Every palette resolves to six CSS variables defined in colors.css. Components reference slots, not steps — bg-[var(--c-solid)] does the right thing whether the palette is brand or pink, in light or dark mode.

Disabled slots

A disabled control should read as inactive whatever its palette, so the disabled slots are deliberately palette-independent — neutral grays declared once on :root / [data-theme="dark"]. Every data-color inherits the same muted set, so they don't repeat per palette. Need a palette-specific disabled look? Override [data-color="x"] { --c-solid-disabled: … } in your own CSS.

Want to see each slot? Here is every palette laid out across all six.

Toggle the docs theme to watch every slot rebalance — the dark map keeps fills bright and surfaces deep so contrast stays put.

Token scales

Every slot above resolves to a step on a deeper token scale — --color-<name>-{25..950}. The kit ships seventeen named scales (plus white and black): five gray flavors and twelve accents. Only the twelve listed in COLORS have a data-color block today; the rest (gray-modern, gray-blue, gray-true, lime, rose) are wired to Tailwind and ready to be promoted — or used directly via bg-rose-500, text-gray-modern-700, etc.

Step 500 is the resting solid for most accents — 400 for yellow, where 500 reads too dim on white. Step 700 is the canonical text token on non-filled surfaces in light mode; 300 in dark. The slot map in colors.css formalises these picks per palette so components never reach past --c-*.

Variants × palette

Each variant binds a small subset of slots. Swap color, the rest follows.

The same twelve palettes drop straight into ActionIcon without a second resolver — data-color is component-agnostic.

Semantic intent through color

There is no destructive, success, or warning variant. Intent rides on color over the right shape — four variants × twelve palettes covers the space without a combinatorial taxonomy.

Surfaces

Distinct from the accent system above: Card (and bordered surfaces generally) aren't meant to pop with a color — they're meant to sit quietly on whatever the host app's page actually looks like. Their default, outline, and gradient variants don't read --c-solid at all. Instead of a fixed hue, they use a flat, low-opacity white wash — bg-white/4, the same value in both light and dark theme. A translucent tint always reads as "a little lighter than whatever's behind it"; a hardcoded opaque fill would look right on the kit's own dark-navy chrome but clash on a host app whose page happens to already be blue, or genuinely white, or anything else the kit doesn't control.

Text and border still adapt to the app's light/dark theme — navy text on a navy-tinted border in light theme, white text on a white-tinted border in dark theme. Only the fill itself stays theme-agnostic and background-dependent.

Same <Card padding="sm">…</Card>, two different backgrounds behind it — the card's own fill never changes, only what shows through it does.

filled and light are the exception: those two variants exist specifically to accept a color and do read the accent slots (--c-solid / --c-soft), same as Button. Reach for them when a surface needs to carry semantic color; reach for default / outline / gradient for a plain content surface that has to work on a page background the kit doesn't control.

Consuming the system in a new component

Every colored component follows the same shape. Bind a handful of slots in cva, then write data-color on the root.

import { cva } from 'class-variance-authority';
import { ark } from '@ark-ui/react';
import { cn } from '@42/ui-react/cn';
import { type Color } from '../../lib/colors';

const variants = cva('...', {
  variants: {
    variant: {
      filled:  'bg-[var(--c-solid)] text-[var(--c-on-solid)] hover:bg-[var(--c-solid-hover)]',
      light:   'bg-[var(--c-soft)]  text-[var(--c-text)]    hover:bg-[var(--c-soft-hover)]',
      outline: 'bg-transparent text-[var(--c-text)] border border-[var(--c-solid)] hover:bg-[var(--c-soft)]',
      subtle:  'bg-transparent text-[var(--c-text)] hover:bg-[var(--c-soft)]',
    },
  },
});

export const Foo = ({ color = "var(--primary-color)", variant, ...rest }: Props) => (
  <ark.button data-color={color} className={cn(variants({ variant }))} {...rest} />
);

One rule to keep the abstraction honest:

• Never reach past the slots. Inside a colored variant, bg-blue-500 is a bug — it breaks dark mode and breaks consumer-defined palettes.

Adding a new color (3 steps)

None of these touch a component file.

1. Define --color-<name>-{25..950} in theme.css.
2. Append the name to COLORS in lib/colors.ts.
3. Add a [data-color="<name>"] block (and a [data-theme="dark"] [data-color="<name>"] override) to colors.css with the six slots.

/* colors.css */
[data-color="indigo"] {
  --c-solid: var(--color-indigo-500);
  --c-solid-hover: var(--color-indigo-600);
  --c-on-solid: var(--color-white);
  --c-soft: var(--color-indigo-50);
  --c-soft-hover: var(--color-indigo-100);
  --c-text: var(--color-indigo-700);
}
[data-theme="dark"] [data-color="indigo"] {
  --c-solid: var(--color-indigo-500);
  --c-solid-hover: var(--color-indigo-400);
  --c-on-solid: var(--color-gray-dark-950);
  --c-soft: var(--color-indigo-950);
  --c-soft-hover: var(--color-indigo-900);
  --c-text: var(--color-indigo-300);
}

Custom palette without forking

Color is (typeof COLORS)[number] | (string & {}), so autocomplete still suggests the twelve built-ins while letting consumers ship their own data-color block in app CSS. Same six slots, same component code, no fork of the kit.

/* app's globals.css */
[data-color="lime"] {
  --c-solid: #84cc16;
  --c-solid-hover: #65a30d;
  --c-on-solid: #0a0d12;
  --c-soft: #ecfccb;
  --c-soft-hover: #d9f99d;
  --c-text: #4d7c0f;
}

<Button color="lime">Custom palette</Button>

API

import { COLORS, type Color } from '@42/ui-react';

COLORS;
// readonly ['brand', 'gray', 'neutral', 'red', 'orange', 'yellow',
//           'green', 'teal', 'cyan', 'blue', 'purple', 'pink']

type Color = (typeof COLORS)[number] | (string & {});

COLORS is exported at runtime for iteration — story controls, this docs page, anywhere you need to enumerate the built-in palettes. Color is the type to accept on any colored prop. Both live on the package root (@42/ui-react); component barrels only re-export their own types.