#Design Tokens

#Design Tokens

Design tokens are semantic CSS custom properties that represent design decisions — such as "background for an action element" or "text color for an error state" — rather than raw color values.

They follow the naming pattern --token-color-{section}-{role} and are the recommended way to reference Eufemia colors in your own CSS.

#Why use design tokens?

• Theme-aware — Token values automatically adapt when the active theme changes (e.g. DNB, Sbanken, Carnegie).
• Semantic — A name like --token-color-background-action communicates intent, not just a hex value. This makes code easier to review and maintain.
• Scalable theming — Design tokens make it straightforward to introduce new brands, sub-brands, and color modes (e.g. light/dark) without changing component code.

#Token audiences

Not all tokens are intended for the same use cases:

• Base — Part of the intended external semantic surface, such as action or action-inverse.
• State — Semantic interaction states, such as action-hover or action-focus.
• Advanced — Contextual or decorative tokens, such as action-ondark, action-onlight or action-subtle.

#Naming contract

Typical examples:

• semantic token: --token-color-text-neutral
• semantic state token: --token-color-background-action-hover-subtle
• component token: --token-color-component-button-background-action

#Getting started

Design tokens are included when you import a Eufemia theme. No separate import is needed.

#Basic usage

Use the var() function to reference a token in your CSS:

.my-component {
  background-color: var(--token-color-background-neutral-subtle);
  color: var(--token-color-text-neutral);
  border: 1px solid var(--token-color-stroke-neutral);
}

.my-component__title {
  color: var(--token-color-text-neutral);
}

.my-component__action {
  background-color: var(--token-color-background-action);
  color: var(--token-color-text-action-inverse);
}

#Token sections

Tokens are organized into sections. Each section covers a specific surface:

See the Tokens tab for the full catalog.

#Common patterns

#Action elements

.my-button {
  background-color: var(--token-color-background-action);
  color: var(--token-color-text-action-inverse);
  border: 1px solid var(--token-color-stroke-action);
}

.my-button:hover {
  background-color: var(--token-color-background-action-hover);
}

#Error and status states

.my-field--error {
  border-color: var(--token-color-stroke-error);
  color: var(--token-color-text-destructive);
}

.my-field--success {
  border-color: var(--token-color-stroke-positive);
}

#Subtle backgrounds

.my-notice {
  background-color: var(--token-color-background-warning-subtle);
  color: var(--token-color-text-warning);
}

#Internal usage in Eufemia components

Eufemia components are progressively adopting design tokens internally. Internally a component might look like:

// Inside dnb-badge.scss
.dnb-badge {
  --badge-information-bg: var(--token-color-background-error);
  --badge-information-color: var(--token-color-text-neutral-inverse);
}

This internal adoption should have no functional downsides when you use a component - the rendered result and public API remain the same. However, be aware of one potential side-effect:

#CSS specificity changes

When a component switches from a hard-coded color value to a var(--token-*) reference, the selector structure of the underlying stylesheet may change. If your application overrides component styles with raw selectors, you may need to verify that your overrides still win the specificity contest.

For example, if you previously overrode a component background with:

/* Your override */
.dnb-badge {
  background-color: hotpink;
}

And the component internally moves that value to a token-based custom property, the specificity of the internal selector might change. In practice this is rare, but if you notice a visual regression after upgrading it is worth checking.

Recommendation: Prefer using the component's own CSS custom properties (e.g. --badge-information-bg) for overrides rather than targeting raw CSS properties. This avoids specificity conflicts entirely.

#Tailwind CSS integration

Design tokens are also available in Tailwind-compatible format. See the CSS Styles page for details on using tokens with Tailwind utility classes.

#Source of truth

• The token inventory is generated from the same exported theme token files that produce the CSS output.
• The consumer API is the generated CSS tokens files.
• The color values behind these tokens come from Eufemia Foundation colors and are mapped into semantic and component token layers per theme.
• Eiendom currently reuses the UI token source, so the three explicit brand references are DNB, Sbanken and Carnegie.