CSS styling

The rules channel is the CSS/Code mode's main tool: a validated CSS dialect that targets named UI parts and sets allowlisted properties on them. You write it in the studio's rules editor (visual form or CSS text — both edit the same model), preview it live, and publish. Developers can drive the same channel over HTTP — see the developer API.

Because everything is validated against a closed contract, a rule can restyle your customers' surfaces but can never leak outside them, import external resources, or break other tenants.

The syntax

Selectors use bare part names — no classes, no DOM knowledge required:

/* every Button, everywhere */
Button {
  border-radius: 9999px;
  font-weight: 600;
}

/* a specific variant */
Button.destructive {
  background-color: #e5484d;
}

/* interaction states are pseudo-classes */
Button:hover {
  background-color: var(--brand-hover);
}

/* part-specific states use [state="..."] */
SelectTrigger[state="open"] {
  border-color: var(--brand);
}

/* scope a rule to one color mode with a .dark / .light prefix */
.dark Card {
  background-color: #1c1f24;
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.3);
}

/* responsive rules go in a min-width media query */
@media (min-width: 768px) {
  Greeting {
    font-size: 2rem;
  }
}

The selector grammar, completely:

Anything else — descendant chains, ids, attribute selectors of your own, unknown parts or states — is a validation error you'll see in the editor.

The parts catalog

The closed set of styleable parts. Parts with variants can be narrowed with .variant; parts with states accept [state="…"] on top of the universal :hover / :focus-visible / :active / :disabled.

The catalog grows over time; the live list is always available from the contract endpoint.

Properties and values

Only these properties can be set, and every value must fully match its grammar — there's no passthrough:

Referencing tokens instead of hex where possible (var(--brand-hover) rather than a hard-coded shade) keeps your rules working when you later change the palette.

Validation: strict where it matters

• Unknown part, variant, state, mode, or breakpoint → error. A typo in targeting is something you need to see.
• Invalid value for a known property → error. A silently dropped value would be a confusing no-op.
• Unknown property → dropped with a warning. The allowlist grows over time, so old rules shouldn't break on new keys.
• Values containing ;, {, }, \, /*, url(, @, <, or > are rejected outright.

A legibility linter also runs on submit: blocking problems (like unreadable contrast against your own theme) stop the draft; softer notes come back as warnings.

Caps

Publish flow

Rules save as immutable, content-addressed drafts — the same rules always produce the same hash. You preview a draft in the studio, then publish the exact hash you previewed. Every publish lands in the version history with one-click restore. The same lifecycle is scriptable through the developer API.