LogoLogo
  • audit and issues
  • useful references
  • positioning idea
  • custom theme
  • Brainstorming
LogoLogo

custom theme

You absolutely can let customers “theme” this renderer—without breaking your current static-publish pipeline—by treating theme as data and layering it on top of your existing CSS variables, Fumadocs UI preset, and the scoped component system you already have.

Below is a pragmatic, staged menu of options (from “simple color picker” to “power-user CSS”) plus how each would plug into your current code paths (renderer + publish), what security constraints to enforce, and what JSON you’d ship to the renderer.

Some random content for deployment - api key mismatch causing trouble!


TL;DR — A layered theming model that fits your stack

  1. Theme tokens (no‑code):
    Expose a tiny set of CSS custom properties (your current :root tokens) as a site “Theme” object your web app saves at publish time. The renderer fetches that JSON and injects a

Previous
positioning idea
Next
Brainstorming
Last updated 3 months ago

On this page

  1. TL;DR — A layered theming model that fits your stack
  2. Product tiers (what users actually see)
  3. A) Quick “Brand” mode (90% of teams)
  4. B) Token editor (designers)
  5. C) Advanced site CSS (power users, safe)
  6. D) Code highlighting theme picker (devs)
  7. Data contract — what the static JSON could look like
  8. Renderer changes (small, surgical)
  9. Publish‑time changes (web service)
  10. Security & isolation
  11. Performance & cache
  12. How this improves UX 100×
  13. Concrete renderer touch points (no code dump; just where/what)
  14. Open choices (each has a safe default)
  15. Why this architecture fits your stack
  16. If you want a quick first milestone