Theme Presets#

Copy as MarkdownView Markdown

Ox Content splits a theme into two independent axes, published as two families of packages:

• Skins (@ox-content/theme-*) own form — geometry, texture, typography and motion. A skin is written entirely against --octc-* custom properties and never names a color.
• Color schemes (@ox-content/theme-color-*) own color — a light and a dark palette, and nothing else. No layout, no texture, no fonts.

Because neither half knows about the other, any skin pairs with any scheme: 27 skins × 45 schemes = 1215 combinations.

Gallery#

Browse every combination →

The gallery renders each pairing with the real SSG stylesheet inside an iframe, so what you see is what a built site looks like — including light and dark, the landing page and an article page, and the live WebGL backdrops.

A sample of every skin — each shot with the colour scheme it was designed toward:

Pixel Liquid Glass Blur Glass Analog Film Fluid Fabric Leather Brutalist Terminal Blueprint Risograph Swiss Neon Clay Editorial Aurora Holo Paper Voltage Manuscript Ledger Kiosk Atlas Receipt Bauhaus Zine Noir

Quick start#

Install one of each:

npm install @ox-content/theme-liquid-glass @ox-content/theme-color-tokyo-night

Then list them as layers. theme accepts an array, and layers compose left to right:

// vite.config.ts
import { defineConfig } from "vite";
import { oxContent } from "@ox-content/vite-plugin";
import liquidGlass from "@ox-content/theme-liquid-glass";
import tokyoNight from "@ox-content/theme-color-tokyo-night";

export default defineConfig({
  plugins: [
    oxContent({
      srcDir: "docs",
      ssg: {
        siteName: "My Docs",
        theme: [liquidGlass, tokyoNight],
      },
    }),
  ],
});

Anything you append wins, so your own overrides go last:

theme: [
  liquidGlass,
  tokyoNight,
  {
    colors: { primary: "#ff5f56" },
    footer: { copyright: "Copyright © 2026 My Company" },
  },
];

Either axis works on its own. A scheme with no skin restyles the default theme; a skin with no scheme reshapes the default palette.

Skins#

Each skin is roughly 6–7 kB of CSS with zero JavaScript and no runtime dependencies.

Color schemes#

Every scheme ships a matched light and dark palette; the built-in header toggle switches between them with no extra configuration.

Syntax highlighting#

Highlighting follows the color scheme in both modes, with no extra configuration. highlightTheme defaults to 'css-variables', so Shiki emits token colors as --octc-shiki-* custom properties and each scheme defines them per mode — one build, two palettes.

Schemes pick syntax colors against the code background, not the page background. Several light schemes (mono, snow, nord, retro, monokai, poimandres, synthwave) deliberately keep a dark code block in light mode; a fixed theme would put dark token colors on it and make it unreadable.

With no scheme installed the properties fall back to GitHub Dark, which is what the default used to be. To bake fixed colors in instead, name any bundled Shiki theme:

oxContent({ highlightTheme: "vitesse-dark" });

Override individual tokens like any other token:

theme: [pixel, tokyoNight, { darkTokens: { "shiki-token-comment": "#5a6a8a" } }];

Motion#

Presets are motion-first, and all of it is declarative CSS:

• Cross-document page transitions via @view-transition { navigation: auto }. The header and sidebar are given view-transition-names so they hold still while the article swaps — an app-like feel with no router and no client bundle.
• Scroll-driven reveals via animation-timeline: view(). Headings, code blocks, tables and feature cards rise as they enter, with the feature grid staggered by column.
• Dialog entry via @starting-style, so the search modal animates open without a JavaScript-toggled class.

Everything sits behind @supports, so an engine that lacks a feature simply renders the finished, static state — the un-animated state is never a hidden one. All of it is disabled under prefers-reduced-motion: reduce.

Retune the choreography without touching CSS. Every skin exposes its timing as tokens:

theme: [liquidGlass, tokyoNight, { tokens: { "motion-base": "200ms", "motion-ease": "linear" } }];

Live backdrops#

Three skins render their hero backdrop on the GPU instead of faking it in CSS:

All three are hand-written WebGL2 with no dependencies — no Three.js, no bundle, nothing to install. They ship inside the theme's own js, which the SSG emits as one inline script.

They are strictly progressive enhancement, and every one of these leaves the page exactly as it renders without JavaScript:

• prefers-reduced-motion: reduce — never starts
• No WebGL2 context, or a shader that fails to compile — never starts
• Hero scrolled out of view, or tab backgrounded — stops drawing
• Any error at all — swallowed, since the CSS backdrop underneath is the design

Colors are read from the live palette through the same --octc-* properties, so a backdrop follows its color scheme and re-reads on every theme toggle.

Custom tokens#

tokens and darkTokens set any --octc-* custom property, keyed without the prefix. They merge key-by-key across layers, so overriding one value never means redeclaring the rest:

theme: [
  liquidGlass,
  tokyoNight,
  {
    tokens: { "surface-glass": "#f8fafc", "code-line-add": "rgba(0,200,120,.18)" },
    darkTokens: { "surface-glass": "#0c1324" },
  },
];

Token names are validated at build time — a name that could break out of its declaration block fails the build rather than shipping a corrupt stylesheet.

How composition works#

resolveTheme flattens every layer's extends chain, then merges the result:

• Object fields (colors, tokens, layout, fonts, …) merge key-by-key, last layer winning.
• css and js concatenate in layer order — overwriting them would discard one half of a skin + scheme stack. Identical fragments are joined once, so a layer reached through both an array and an extends chain is not emitted twice.

That ordering is why a skin declares its surface variables through tokens rather than raw css: tokens resolve declaratively before any stylesheet runs, which keeps the outcome independent of the order you list the packages in.

Writing your own#

A preset is a plain ThemeConfig — there is no plugin API to implement. A skin sets css, fonts, layout and motion tokens; a scheme sets colors, darkColors, tokens and darkTokens.

import { defineTheme } from "@ox-content/vite-plugin";

export default defineTheme({
  name: "my-skin",
  fonts: { sans: "Inter, system-ui, sans-serif" },
  tokens: { "motion-base": "260ms", "motion-ease": "cubic-bezier(.2,0,0,1)" },
  css: `.header { border-bottom: 2px solid var(--octc-color-primary); }`,
});

The one rule that keeps a skin composable: never name a color. Reference --octc-color-* and --octc-accent-*, and reach for color-mix() when you need a tint. Neutral black/white alpha for depth is fine, since it reads correctly over any palette.