SDS 3.27.0 changed how SDS color tokens are generated and used. The visible palette is still the SDS palette, but the underlying CSS values now use modern color syntax, complete custom property values, and browser-native light and dark mode switching.

These changes make SDS colors easier to use in application CSS, more consistent across light and dark themes, and better aligned with current CSS color standards.

From RGB channels to OKLCH colors

Older SDS color custom properties were stored as RGB string values. A color variable such as --color-celeste expanded to a string, so CSS had to wrap it in rgb() before the browser could use it as a color.

SDS color variables are now complete CSS color values. Most palette tokens are emitted as oklch(...) values.

OKLCH is a modern CSS color format with three main channels:

OKLCH is useful for design systems because changes to lightness and chroma are more predictable than equivalent changes in RGB or HSL. That gives SDS a better base for generating scales, tints, transparent mixes, gradients, and dark mode mappings.

Dynamic colors

SDS has always had two useful ways to refer to colors. The latest SDS does not change this, but behind the scenes instead of duplicating CSS variable definitions and redefining them when the theme changes, SDS now uses the new css light-dark() function to define dynamic colors.

The two main ways to refer to colors in SDS are dynamic named colors and fixed numbered colors:

• Dynamic named colors, such as --color-default, --color-celeste-bright, and --color-ink-dark, follow the active light and dark mode theme.
• Fixed numbered colors, such as --color-ink-900 or --color-celeste-600, always refer to a specific color and do not change with the theme.

Prefer dynamic named colors for UI styling because they follow the active theme.

.surface {
  color: var(--color-default);
  background-color: var(--color-celeste-bright);
  border-color: var(--color-blue-lightest);
}

Use fixed numbered colors when you intentionally need a specific palette value, such as a brand swatch, data visualization color, or documentation sample.

.brand-swatch {
  background-color: var(--color-celeste-600);
}

With SDS 3.27.0, dynamic named colors use the CSS light-dark() color function behind the scenes.

:root {
  --color-celeste-shade: light-dark(var(--color-celeste-600), var(--color-celeste-400));
  --color-red-lightest: light-dark(var(--color-red-100), var(--color-red-900));
}

light-dark(lightValue, darkValue) lets the browser choose between two color values based on the element’s active color scheme. SDS sets color-scheme: light dark at the token level, and theme controls such as ds-theme can switch the active mode by setting the SDS theme attribute.

This not only simplifies the CSS, but also makes it easier to maintain and update color values across the design system - and more importantly, allows us to take advantage of future css color functions.

Syntax changes

The biggest migration rule is simple: use SDS color variables directly.

For normal color usage, remove the rgb() wrapper

For transparent color usage, remove the rgb() wrapper, and use oklch(from …)

With complete OKLCH color variables, use oklch(from ...).

Do not wrap SDS color variables in rgb(), rgba(), hsl(), or oklch(). The variable already includes the color function.

Migration checklist

• Replace rgb(var(--color-*)); with var(--color-*).
• Replace rgb(var(--color-*) / <alpha>) with oklch(from var(--color-*) l c h / <alpha>).
• Pass SDS color variables directly into component custom properties.
• Prefer named dynamic colors such as --color-default, --color-background, and --color-ink-dark.
• Use numbered colors only when a fixed palette step is required.
• Let light-dark() backed SDS tokens handle light and dark mode where possible.
• Use ds-input --color-picker for native color inputs that need SDS styling.

The result is less wrapper syntax, clearer color intent, better light and dark mode behavior, and a color system that matches modern browser capabilities.