Theming the headless chrome

Import @dashfoo/react/styles.css once before your theme, including when building a custom skin. It supplies the required structural rules and uses CSS custom properties for runtime geometry.

@dashfoo/react renders the dock as plain DOM with zero imposed styling: no class names, no inline colors, no default border on a tabset. Every structural element instead carries a data-dashfoo="..." attribute (and the resize splitters carry data-separator from react-resizable-panels). You style a skin by selecting on those attributes.

You have two paths:

1. Import the default skin. @dashfoo/theme ships a complete skin over overridable --dashfoo-* tokens, light by default with an opt-in dark variant. Most apps want this. The full token table is in Design tokens and the dark theme below. Tailwind v4 apps import the source entry into their pipeline; everyone else imports the prebuilt CSS (compiled from the same source, no build step):

   Copy Text

   /* Tailwind v4 apps; also generates bg-dashfoo-* etc. utilities */
   @import "tailwindcss";
   @import "@dashfoo/theme/tailwind.css";

   Copy Text

   // Apps without Tailwind; prebuilt, zero build
   import "@dashfoo/react/styles.css";
   import "@dashfoo/theme/dashfoo.css";

2. Write your own. Select on the data-dashfoo attributes from a regular CSS file. There is no theme provider, no style props, and no runtime config. This guide is the full attribute + state + token contract you'd target.

The examples below are plain CSS. If your app uses Tailwind you can @apply equivalents. The selectors are the same either way. The canonical worked skin is packages/theme/src/css/skin.css.

Using the theme with Tailwind v4Copy Anchor Link

The @dashfoo/theme/tailwind.css entry does three things on top of the skin:

• Tokens land in Tailwind's theme layer and the skin rules in the components layer, so your utilities and unlayered CSS override the skin without specificity wars. Import the theme before your own component-layer CSS.
• An @theme inline block bridges the tokens into Tailwind, generating dashfoo-* utilities for your own markup: bg-/text-/border-/ring- for the 11 color tokens, rounded-dashfoo / rounded-dashfoo-sm, and font-dashfoo. Because the utilities inline var(--dashfoo-*), they follow the [data-dashfoo-theme="dark"] remap automatically, so no dark: variant is needed.
• Custom CSS should keep reading var(--dashfoo-*), never the --color-dashfoo-* mirrors. The mirrors resolve at :root and ignore subtree dark remaps.

Why attributes instead of class namesCopy Anchor Link

Two reasons drive the choice.

1. Nothing to override. A library that ships default styles forces you into specificity wars or !important to undo them. dashfoo ships none, so your first rule is also the only rule that matches.

2. Stable selectors. Class names churn across versions and get mangled by CSS-in-JS. The data-dashfoo values are part of the public contract: they change with a major version, not a refactor. Select on them the same way you would select on role or aria-*.

The shipped theme leans into this. It is one flat block of attribute selectors in plain CSS, every value resolving through a --dashfoo-* token:

[data-dashfoo="layout"] {
  background: var(--dashfoo-background);
  color: var(--dashfoo-foreground);
  font-family: var(--dashfoo-font);
}
[data-dashfoo="tabset"] {
  flex: 1 1 0%;
  overflow: hidden;
  border: 1px solid var(--dashfoo-border);
  border-radius: var(--dashfoo-radius);
  background: var(--dashfoo-card);
}
/* ...one rule per attribute... */

Nothing here is dashfoo-specific machinery. The same selectors work in any CSS dialect.

Attribute referenceCopy Anchor Link

Every value of data-dashfoo the renderer emits, what element carries it, and where it comes from. Read the right-hand column against the source files if you want to confirm a selector before you write the rule.

A few of these warrant detail.

Tabset structureCopy Anchor Link

A tabset nests four levels deep. The skin styles each separately so the strip, the tabs, and the content panel can have different surfaces.

<div data-dashfoo="tabset">
  <div data-dashfoo="tabstrip">
    <div data-dashfoo="tablist">
      <span role="tablist" aria-owns="…" />
      <span data-dashfoo="tab-item">
        <button data-dashfoo="tab" role="tab" aria-selected="true">Editor</button>
        <button data-dashfoo="tab-close" aria-label="Close Editor">…</button>
      </span>
    </div>
    <div data-dashfoo="tabset-toolbar">
      <button data-dashfoo="tabset-maximize" aria-pressed="false">…</button>
    </div>
  </div>
  <div data-dashfoo="tabcontent" role="tabpanel">…</div>
</div>

tablist is the scrolling viewport. The empty role="tablist" span inside it owns the tab buttons by id through aria-owns, so close buttons and rename inputs stay siblings in the accessibility tree instead of invalid tablist children. It has no data-dashfoo value: leave it unstyled.

The shipped theme treats the tabset as a card and the strip as its header:

[data-dashfoo="tabset"] {
  overflow: hidden;
  background: var(--dashfoo-card);
  border: 1px solid var(--dashfoo-border);
  border-radius: var(--dashfoo-radius);
}
[data-dashfoo="tabstrip"] {
  background: var(--dashfoo-muted);
  border-bottom: 1px solid var(--dashfoo-border);
}
[data-dashfoo="tabcontent"] {
  background: var(--dashfoo-card);
}

The tab-rename inputCopy Anchor Link

There is no rename mode you opt a class into. When a renamable tab is double-clicked, the tab button is swapped for an <input data-dashfoo="tab-rename"> in place. Style it as a normal text field; it focuses and selects itself on mount, commits on Enter or blur, and cancels on Escape.

[data-dashfoo="tab-rename"] {
  width: 6rem;
  padding: 0.25rem 0.5rem;
  background: var(--dashfoo-background);
  border: 1px solid var(--dashfoo-ring);
  border-radius: 2px;
  color: var(--dashfoo-foreground);
  outline: none;
}

State hooksCopy Anchor Link

State does not arrive as extra data-dashfoo values. It rides on the native ARIA and data-* attributes the elements already set, so your selectors compose the structural attribute with the state attribute.

The boolean data-* attributes (data-dragging, data-dragging-source) are only present when true. They are set to undefined otherwise, so the attribute is absent rather than ="false". Select on presence:

[data-dashfoo="tab-item"][data-dragging] {
  opacity: 0.35;
}
[data-dashfoo="tabset"][data-dragging-source] {
  /* the tabset being dragged away by its grip; dim/dash it */
  border-style: dashed;
}

There is no "drop target" attribute. Where a drop will land is shown by the single [data-dashfoo="dock-indicator"] overlay, not by a class on the target.

Selected tabCopy Anchor Link

The theme reads selection through aria-selected and adds a weight change plus an underline pseudo-element. No color is used to carry the state on its own, which keeps it legible without hue:

[data-dashfoo="tab"] {
  cursor: pointer;
  background: transparent;
  border: 0;
  color: var(--dashfoo-muted-foreground);
}
[data-dashfoo="tab"][aria-selected="true"] {
  color: var(--dashfoo-foreground);
  font-weight: 500;
}
[data-dashfoo="tab-item"]:has([aria-selected="true"]) {
  background: var(--dashfoo-card);
}
[data-dashfoo="tab-item"]:has([aria-selected="true"])::after {
  content: "";
  position: absolute;
  inset-inline: 0.5rem;
  bottom: -1px;
  height: 2px;
  border-radius: 9999px;
  background: var(--dashfoo-primary);
}

The active surface and the underline want to sit on the tab-item wrapper, but the state lives on the inner tab button. :has() lifts the state up one level without any extra attribute on the wrapper.

Pressed maximize toggleCopy Anchor Link

The maximize button reports its on/off state through aria-pressed. Give the pressed toggle a visible surface, e.g. with the hover tokens:

[data-dashfoo="tabset-maximize"][aria-pressed="true"] {
  background: var(--dashfoo-accent);
  color: var(--dashfoo-accent-foreground);
}

The splitterCopy Anchor Link

The resize handle is a react-resizable-panels <Separator>. It carries both data-dashfoo="splitter" (dashfoo's hook) and data-separator with aria-orientation set by rrp. Orientation lives on the separator itself, so you read direction from the attribute rather than from the parent row.

The handle is invisible by default. The theme gives it a wide hit area with the right cursor per orientation, then paints a thin pill with a ::before so the visual grip is narrower than the grab target:

[data-separator] {
  position: relative;
  display: flex;
  align-items: center;
  justify-content: center;
  background: transparent;
}
[data-separator][aria-orientation="vertical"] {
  width: var(--dashfoo-splitter-size);
  cursor: col-resize;
}
[data-separator][aria-orientation="horizontal"] {
  height: var(--dashfoo-splitter-size);
  cursor: row-resize;
}
[data-separator]::before {
  content: "";
  background: var(--dashfoo-ring);
  border-radius: 9999px;
}
[data-separator][aria-orientation="vertical"]::before {
  width: 2px;
  height: 2rem;
}
[data-separator][aria-orientation="horizontal"]::before {
  width: 2rem;
  height: 2px;
}
[data-separator]:hover::before {
  background: var(--dashfoo-foreground);
}

A 16px grab target around a 2px grip keeps resize easy to hit while the visible line stays quiet. The hover rule raises contrast on the grip, not the whole handle.

Magnetic snappingCopy Anchor Link

When snapping is on and a drag locks the boundary to the grid, the adapter writes two transient attributes that the theme styles without inline color:

The transition is scoped to the snapping group only, so free-drag tracking stays 1:1 with the pointer. The boundary glides onto the line and snaps off it instantly.

Dock indicators and the --dashfoo-dock-* varsCopy Anchor Link

The drag overlay is the one place dashfoo writes color inline, and only as a fallback. While a tab is dragged, a single data-dashfoo="dock-indicator" element is positioned over the frame. Its position and size are fixed inline (the library computes them from geometry), but every visual property reads a CSS custom property with a neutral fallback. Set the variables to own the look without touching the element's selector.

The indicator takes two visual forms from the same element. Dropping onto a tab strip paints a thin insertion line at the slot boundary, with --dashfoo-dock-line-radius for its ends; dropping onto the tabset body to split paints a filled pane covering the zone. Both share the same fill and border vars, so setting them covers both forms.

The shipped theme derives the two color vars from its semantic tokens, so the indicators follow the light and dark palettes automatically:

:root {
  --dashfoo-dock-fill: color-mix(in oklab, var(--dashfoo-primary) 10%, transparent);
  --dashfoo-dock-border: var(--dashfoo-ring);
}

If you want the indicator to follow your accent color, point these at your own tokens:

:root {
  --dashfoo-dock-fill: color-mix(in oklab, var(--accent) 18%, transparent);
  --dashfoo-dock-border: var(--accent);
}

You can still select [data-dashfoo="dock-indicator"] directly for properties the vars do not cover, such as box-shadow. The inline left/top/width/height are owned by the library; leave those alone or the indicator will not track the pointer.

Focus and hit targetsCopy Anchor Link

The renderer wires the keyboard model (roving tabindex on the tablist, arrow keys to move selection, Home/End to jump). The skin owns the visible focus ring. The theme draws the tab's ring on the tab-item wrapper as an inset box-shadow, so it wraps the label plus close button without clipping against the tabset's overflow: hidden edge; the icon controls take a plain outline:

[data-dashfoo="tab"]:focus-visible {
  outline: none;
}
[data-dashfoo="tab-item"]:has([data-dashfoo="tab"]:focus-visible) {
  border-radius: 0.375rem;
  box-shadow: inset 0 0 0 2px var(--dashfoo-ring);
}
[data-dashfoo="tab-close"]:focus-visible {
  outline: 2px solid var(--dashfoo-ring);
}
[data-dashfoo="tabset-maximize"]:focus-visible {
  outline: 2px solid var(--dashfoo-ring);
}

Mind hit-target sizes on the icon controls. The theme gives tab-close a 16px box and tabset-maximize a 24px box. The close control sits inside a larger tab-item hover zone, but on touch you may want to grow both to meet the 44px target guidance.

Design tokens and the dark themeCopy Anchor Link

If you import @dashfoo/theme, you reskin by remapping the shadcn-style --dashfoo-* tokens rather than rewriting rules. The tokens are defined in packages/theme/src/css/tokens.css and are the intended override surface. The dark variant under [data-dashfoo-theme="dark"] remaps the same names with the inverted neutral scale.

The three optional dock tokens from the indicator table above (--dashfoo-dock-border-width, --dashfoo-dock-radius, --dashfoo-dock-transition) are unset by default and complete the set: 21 overridable tokens in total.

Splitter size. --dashfoo-splitter-size is the default; the model's global.splitterSize (a number, in px) overrides it per-layout via an inline CSS var on the layout root.

A reskin is a token remap on :root (or any scope):

:root {
  --dashfoo-background: #0b0f17;
  --dashfoo-card: #131a26;
  --dashfoo-foreground: #e8f0ff;
  --dashfoo-radius: 6px;
}

Dark is opt-in. The theme ships light by default; set data-dashfoo-theme="dark" on any ancestor to invert the grayscale for that subtree:

<html data-dashfoo-theme="dark"></html>

You can also define your own light/dark token blocks (e.g. under @media (prefers-color-scheme: dark)) if you're writing the skin from scratch.

Starting your own skinCopy Anchor Link

A minimal skin needs four blocks: the layout surface, the tabset card, the tabs with their selected state, and the splitter. Everything else is refinement.

[data-dashfoo="layout"] {
  background: oklch(1 0 0);
  color: oklch(0.145 0 0);
  padding: 1rem;
}
[data-dashfoo="tabset"] {
  border: 1px solid oklch(0.922 0 0);
  border-radius: 10px;
  background: oklch(1 0 0);
  overflow: hidden;
}
[data-dashfoo="tab"] {
  border: 0;
  background: transparent;
  color: oklch(0.556 0 0);
  padding: 7px 12px;
  cursor: pointer;
}
[data-dashfoo="tab"][aria-selected="true"] {
  color: oklch(0.145 0 0);
  font-weight: 500;
}
[data-separator][aria-orientation="vertical"] {
  width: 8px;
  cursor: col-resize;
}
[data-separator][aria-orientation="horizontal"] {
  height: 8px;
  cursor: row-resize;
}

Add the dock variables on :root, then fill in tab-close, tabset-maximize, focus rings, and hover states as you go. The full reference for what you can target is the attribute and state tables above.

See alsoCopy Anchor Link

• packages/theme/src/css/skin.css for the complete worked skin, and packages/theme/src/css/tokens.css for the token defaults + dark overrides.
• apps/demo-vite/src/index.css for how the demo imports the theme.
• packages/react/src/components/tabset/tabset-view.tsx for the tabset markup and ARIA wiring.
• packages/react/src/components/row-view.tsx for the splitter (<Separator data-dashfoo="splitter">).
• packages/react/src/components/drag-provider.tsx for the dock indicator and the --dashfoo-dock-* fallbacks.