# Theming System — Design Plan **Status:** Future (post-MVP) **Package:** `@atbb/web` **Goal:** Admin-customizable forum themes with a neobrutal default, inspired by phpBB's theme flexibility. --- ## Design Principles 1. **Admin control without code.** Forum admins pick a theme or tweak design tokens from an admin panel — no CSS authoring needed. 2. **Theme-as-data.** Themes are serializable JSON stored as AT Proto records on the Forum DID's PDS, making them portable and versionable. 3. **Progressive enhancement.** The base HTML is semantic and readable with no styles at all (it already is). Themes layer on top via CSS custom properties. If CSS fails to load, the forum is still usable. 4. **No build step per theme.** Themes are applied at runtime through CSS custom properties and a server-rendered `│ │ } │ │ + /static/theme.css │ └─────────────────────────────┘ └───────────────────────────────────┘ ``` 1. **Theme records** live on the Forum DID's PDS as `space.atbb.forum.theme` records. A forum can have many saved themes. 2. **Theme policy** is a separate singleton record (`space.atbb.forum.themePolicy`) that controls which themes are available to users, which are the defaults for light/dark mode, and whether users can choose their own. 3. **On each request**, the web server resolves which theme to render (see [Theme Resolution](#theme-resolution) below) and injects the winning theme's CSS custom properties into a ` {theme.fontUrls?.map(url => ( ))} {theme.cssOverrides && ( )} ``` The `location.reload()` is intentional — it keeps the "server renders everything" model clean. The server re-renders the page with the other default theme's tokens. Could be enhanced later with HTMX to swap just the `