Nusa UINusa UI

IDDS foundation tokens and styling guidance for Nusa UI.

Nusa UI uses Tailwind CSS v4 with INA Digital Design System (IDDS) foundation tokens. The default brand is INAgov, with a local bridge that keeps shadcn-compatible tokens working for existing registry components.

IDDS Tokens

  • Use IDDS utilities for new foundation-aware surfaces: bg-background-primary, bg-background-secondary, text-content-primary, text-content-secondary, border-stroke-primary, and border-stroke-secondary.
  • Use INAgov brand utilities for product accents: bg-primary-50, bg-primary-100, bg-primary-500, text-primary-700, and border-primary-200.
  • Use sentiment/content tokens for state: text-content-positive, text-content-negative, bg-positive-50, bg-negative-50, and bg-warning-50.

Spacing Tokens

Nusa UI exposes INA Digital primitive spacing tokens as Tailwind utilities with the spacing-* key. Use these for new foundation-aware layouts, for example gap-spacing-16, p-spacing-24, or mt-spacing-32.

TokenValue
spacing-00
spacing-22px
spacing-44px
spacing-88px
spacing-1212px
spacing-1616px
spacing-2424px
spacing-3232px
spacing-4040px
spacing-4848px
spacing-5656px
spacing-6464px
spacing-8080px
spacing-128128px

The default Tailwind numeric scale remains available for existing registry components, so p-4 still behaves like Tailwind while p-spacing-16 maps to the INA Digital token.

Compatibility Bridge

Existing registry components can keep using shadcn-style semantic tokens. These are mapped to IDDS variables in src/app/globals.css:

  • bg-background and text-foreground map to IDDS background/content tokens.
  • bg-primary, text-primary-foreground, and ring-ring map to INAgov brand tokens.
  • bg-card, bg-muted, border-border, and text-muted-foreground map to IDDS surface, stroke, and secondary content tokens.

Rules

  • Use gap-* instead of space-*
  • Use size-* when width and height match
  • Use cn() for conditional Tailwind class merging
  • Use Tabler icons for new work and keep Lucide only for legacy components
  • Prefer IDDS token utilities over raw color values for new work
  • Keep component-level styling on semantic tokens so brand and light/dark modes remain swappable