Theme Presets#

Copy as MarkdownView Markdown

This page and the theme gallery are the official catalog of published skins and color schemes — a stable product surface, not an experiment. Packages follow the authoring contract below so any skin pairs with any scheme.

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 package: 27 skins × 46 color packages = 1242 package pairings. The gallery also lists named migration variants, for 64 scheme rows × 27 skins = 1728 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.

Preview every color package as paired light and dark surfaces. Each card samples the page background, text, link accent, code background, and syntax accent set for one scheme; open the gallery to try it with any skin.

Shiki Migration Presets#

Ox Content 3 highlights code with its native tree-sitter highlighter only. It does not restore the Shiki runtime, highlightTheme, TextMate grammars, or a second highlighting engine. The table below maps official @shikijs/themes@4.4.3 IDs (MIT) to full Ox Content ThemeConfig exports.

Each export remains a paired light/dark theme. When Shiki ships only one side of a family, the pairing column names the stable companion Ox Content uses. Syntax colors are mapped to Ox Content semantic roles (comment, punctuation, keyword, string, constant, function, parameter, and link); exact TextMate scope fidelity is intentionally out of scope.

Syntax highlighting#

Highlighting follows the color scheme in both modes, with no extra configuration. The native tree-sitter highlighter emits token colors as --octc-syntax-* 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.

Override individual tokens like any other token:

theme: [pixel, tokyoNight, { darkTokens: { "syntax-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.

Authoring a package#

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. New packages must meet the compatibility contract below so they compose with every other published layer.

Compatibility#

• Light and dark. Color schemes must export a ThemeConfig (default or named) with both colors and darkColors. Required palette keys: primary, background, text, textMuted, border, codeBackground, and codeText. Catalog schemes also ship primaryHover and backgroundAlt.
• Required syntax tokens. Schemes must define highlighter tokens under tokens and darkTokens: at least syntax-foreground, syntax-background, and several syntax-token-* keys. These become --octc-syntax-* custom properties that theme-color packages resolve.
• Skins must not hard-code colors. A skin owns form, not palette. Do not put hex or rgb values in ThemeConfig.colors / darkColors. CSS variables and omitted color fields are allowed. In css, reference --octc-color-* and --octc-accent-*, and use color-mix() for tints. Neutral black/white alpha for depth is fine.
• Compose left to right. List layers in ssg.theme as an array. Object fields merge key-by-key; css and js concatenate. Later layers win.
• Screenshot. Include a screenshot of the skin (or a representative pairing) for the gallery above.

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); }`,
});

Default theme quality#

The built-in stylesheet (ssg.css) is the quality floor every skin and scheme composes onto. Override these tokens instead of hardcoding a second set of values:

html smooth-scrolling is gated behind prefers-reduced-motion: no-preference. Code-line dim blur and nav chevron transitions turn off when motion is reduced. PR benchmarks still report default theme CSS/JS size — prefer retuning these tokens over adding chrome.

Out of scope here: self-hosted fonts, Iconify CSS, tweet/full-card styling, print stylesheets, and per-skin gallery screenshot refreshes. File those as focused follow-ups when they regress.