Token contract

Every --slide-* custom property declared in @thebuilder/deckard-core/styles.css, its neutral default, and which part of the runtime reads it.

@thebuilder/deckard-core/styles.css declares every --slide-* token with a neutral default, inside @layer base. A theme redefines them on the canvas and wins, because it ships unlayered CSS and everything in the contract sits in the base layer.

The runtime depends on these names and never on a preset, so a deck with no theme still renders: neutral sizes, app surfaces, no decoration.

@import "tailwindcss";
@import "@thebuilder/deckard-core/styles.css";

Type

Every size is set against the 1920x1080 canvas at a 16px root, so 1rem is 16 canvas pixels and the scale reads the way it does on a projector rather than the way it does in a browser window. Multiply a default above by 16 to get what it measures on a canvas 1080 pixels tall.

Line height rides along as a unitless multiplier in the blocks, so changing a size token keeps its leading proportional. Never pair a size token with a fixed leading-7.

Spacing

The frame those gutters leave is the whole slide, left aligned and uncapped: content starts at the left margin and runs to the right one. Blocks cap their own measure where prose needs it, and anything that wants to be centred centres itself.

Figures

Surfaces

Backgrounds

SlideBackground renders one empty element carrying data-slide-background, and the theme paints each variant with these:

There is no radial wash, veil, glow or spotlight token. The textures a theme has are flat colour, a rule, a grid, and a hatch, because a radial gradient reads as a smudge on a projector and as grey on paper.

The four --slide-motion-* tokens are read off the canvas by the animated background, and only for a variant the theme names in motion. See Motion backgrounds. A theme sets them per variant and per color mode the way it sets everything else it paints:

.aurora-theme .slide-background[data-slide-background="hero"] {
  --slide-motion-color-1: #0a0d1f;
  --slide-motion-color-2: #3a2f86;
  --slide-motion-color-3: #1c7c96;
  background: linear-gradient(160deg, #0a0d1f, #1c2350);
}

That background is what the slide shows while the runtime loads, when the browser has no WebGL, and when the context is lost, so paint a variant you animate as though it never would.

Media

Chrome

The colours, type, and spacing of the header and footer, plus the canvas each is allowed:

A theme that redesigns the chrome to a different height sets --slide-header-space and --slide-footer-space, and the slide content moves with it.

Published by the runtime

These are set in the DOM rather than declared in the contract, and a theme or a block reads them:

A fullscreen block pads against the chrome insets so the deck header and slide counter never sit on top of a caption:

className="pb-[calc(3rem+var(--slide-chrome-bottom,0px))]"

Structural attributes

The runtime renders these and the theme styles them. They are as much a part of the contract as the tokens.

These are the other half of the theme contract. Tokens are values; attributes are parts. A theme styles them, decorative ::before and ::after content included, which is how phosphor writes [x] where a list marker goes and ledger hangs a rule there instead, neither of them touching the block. A block may rewrite its markup and its class names freely as long as the attributes stay where they are.

A theme styles parts. It does not add content. A boot log, a status table, a cursor line with words in it are slide content, so they belong in a block the deck composes.

Code blocks are scoped too: [data-slide-canvas] .shiki has its shiki-painted background forced transparent, so a deck never restyles code the surrounding app renders.