Skip to main content
Urbicon UI

Editorial Theme

A token-only overlay on top of the Urbicon UI library that drives the look of this docs site — warm cream paper, mono meta-font, pipe markers. Activated via a single body class; everything else is CSS custom properties.

What it is

The Editorial Theme is the visual identity of this docs site — warm cream paper, generous hairlines, a mono meta-font for ON THIS PAGE / / / breadcrumbs and code-pills, the vertical pipe accent next to page titles. It is implemented as a single CSS file (apps/docs/src/lib/style/editorial.css) that defines a private --docs-* token namespace and binds a handful of library semantic tokens to those values when .docs-editorial is present on the <body>.

Nothing in the library has been forked or duplicated. Every primitive still ships with its library-default look; the Editorial style is a thin token-override sheet over the top. Without .docs-editorial the same page renders in the library defaults — that's the test of whether the docs site really is theme-only.

Editorial vs. Consumer Apps

The Editorial theme is docs-only. Consumer apps that depend on @urbicon-ui/blocks (apps that consume @urbicon-ui/blocks) do not import editorial.css and do not set .docs-editorial; they live on the library defaults and customise via the regular customization ladder (class / slotClasses / preset / defaults / overrides / unstyled).

Token Catalogue

The --docs-* namespace holds the Editorial-specific tokens. The Editorial sheet also binds a handful of library semantic tokens to these values so that components rendered inside .docs-editorial pick up the warm palette without per-component opt-in.

Editorial-private tokens

TokenDefault (light · dark)Used for
--docs-bg#f7f5f0 · #1a1816Ground — the page surface outside content blocks.
--docs-paper#fbfaf6 · #232220Content surface — where library components sit.
--docs-ink#2a2926 · #f0ede5Primary text ink.
--docs-soft#6e6b64 · #a5a299Body-soft / meta ink (ON THIS PAGE labels, descriptions).
--docs-softer#b8b5ad · #5a574fDecoration ink — `//` prefix, separators.
--docs-hairink/8% · ink/8%Hairline — barely-visible structural lines.
--docs-lineink/14% · ink/14%Stronger structural line (section separators).
--docs-accentvar(--color-primary)Pipe marker, link colour — couples to library primary.
--docs-radius-pillvar(--radius-commit)TOC crumbs, meta-chips, section markers.
--docs-radius-cardvar(--radius-2xl)Bento-cards, recipe-stages, theme-builder demo frames.
--docs-shadow-pagevar(--blocks-shadow-lg)Editorial lift shadow — bento, recipe, showcase stages.
--font-monoJetBrains Mono · system monoCode, kbd, meta labels (self-hosted via @fontsource).

Library semantic overrides

The Editorial sheet rebinds these library semantic tokens inside .docs-editorial so library components automatically pick up the warm palette without an explicit opt-in. Everything else (surface-elevated / -overlay, intent colours, focus rings) stays at library defaults — popovers and tooltips read as the library's neutral chrome, which preserves a subtle "chrome vs. content" register against the paper.

Library tokenEditorial value
--color-surface-basevar(--docs-paper)
--color-surface-quietvar(--docs-bg)
--color-border-hairlinevar(--docs-hair)
--color-text-primaryvar(--docs-ink)
--color-text-secondaryvar(--docs-soft)
--color-text-tertiaryvar(--docs-soft)
--color-text-quaternaryvar(--docs-softer)

Activation

The theme activates when .docs-editorial sits on a parent of your content. The docs site puts it on <body> so the whole app inherits the warm canvas. The class only adds Editorial; it does not disable anything from the library.

1. Set the body class

Loading...
Loading syntax highlighting...

And import the stylesheet alongside the library base:

2. Import editorial.css

Loading...
Loading syntax highlighting...

Remove the class (e.g. on a route or wrapper element that should render in library defaults) and the page falls back to the library look. The underlying override mechanism is the same CSS-custom-property cascade documented in Tier System — Editorial just rebinds a wider set of tokens.

Light & Dark

Editorial supports both light and dark out of the box — Light is warm cream paper with warm dark ink, Dark is warm coffee paper with warm cream ink. The shape (paper hierarchy, ink hierarchy, accent, mono meta) is identical across modes so the Editorial identity holds.

Implementation uses CSS's light-dark() function. Each token resolves at use-site based on the page's color-scheme, which the library's semantic layer sets via :root.light / :root.dark. A single rule block covers both modes — no second sheet, no JS-driven swap.

Light/Dark via light-dark()

Loading...
Loading syntax highlighting...

The same mechanism powers semantic.css — see Design Tokens for the library-side details.

Override Recipes

Because every Editorial value lives on a CSS custom property, you can adjust the theme at any scope — globally inside .docs-editorial, on a narrower wrapper, or inline. A few common adjustments:

Common overrides

Loading...
Loading syntax highlighting...

For brand-wide theming (the library's primary colour, the tier radii) reach for the Theme Builder or write a custom @theme block — Editorial sits on top of that and inherits it via the --color-primary and --radius-* chain.