Presentation & theming

What the Themes screen manages — and why look-and-feel is runtime data instead of code.

What it is

A theme is one self-contained CSS file defining the app's full design-token contract (--ns-* custom properties); the active theme per surface — public site and admin back-office independently — is a D1 settings row an admin flips at /admin/themes. Components consume only the token contract, so switching themes restyles everything with no rebuild and no deploy.

Why it exists

NanaSelect has to look like NanaWall today, but presentation is one of the things the product deliberately experiments on: the 2026 presentation push runs multiple deepened themes and layouts side by side, and an experiment can split visitors between theme + layout variants to find the one that converts. That only works if presentation is data a runtime can switch, not code a release ships.

Separating the two surfaces (public vs. admin) means the back-office can stay stable and utilitarian while the buyer experience is restyled freely — changing one never restyles the other. And because a theme is a single token file, a bad theme degrades safely: a stale or invalid stored value falls back to the surface default rather than breaking rendering.

In the admin

Screen	How-to
Themes	Switching themes

Learn more

• Theming reference — the architecture and how to author a new theme.
• Site chrome — the shell the theme skins.
• Experimentation — testing presentations against each other.