Add Dark Mode

[M4dhav]

Dark mode in 2026 is basically a necessity

[shockalotti]

Agreed, and thanks for flagging it.

Worth knowing where this actually stands, because it is further along than it looks in one half and not started in the other.

The admin app is mostly done and simply switched off. frontend/src/app.css already carries a full .dark token block, and every shadcn component we use has dark: variants. Nothing ever applies the class and there is no toggle, so the remaining work is a theme store, a toggle in the UI, persistence, and setting the class before first paint so there is no white flash. That part is small.

The public pages are the real work. The booking page, the manage page and the embed widget all share internal/handler/templates/booking.css, which is hand-written for a light theme with hardcoded colours. Getting dark mode there means turning that file into a small set of semantic variables (--surface, --border, --fg, --muted, and so on) and a dark block that overrides them. One file, but three surfaces benefit, which is why it is worth doing properly rather than per page.

Two design questions I would want settled first, so if you have a view, say it:

1. Should the public booking page follow the visitor system preference, or the operator setting, or both with the operator winning?
2. For the embed widget specifically, following the system preference can clash with a host site that is deliberately the opposite. I lean toward following the system preference there too, because guessing the host page theme is unreliable, but a per-instance override is cheap to add.

One thing it will not cover: the emails. There is no dependable dark mode in mail clients, so those stay light.

If you want to take the admin half, it is a good contained piece of work: a theme store plus a toggle plus the pre-paint class, no backend change unless you want the preference stored per user. Two caveats. It touches frontend/src/lib/components/ui/** and app.css, so pnpm test:visual has to pass, and that is a real-browser test rather than a unit test. And there is currently no theme column on users, so per-user persistence is a small migration on top.

No promise on when I get to the CSS conversion, but the admin half plus the design answers above would make this shippable in two steps instead of one.

[M4dhav]

Should the public booking page follow the visitor system preference, or the operator setting, or both with the operator winning?

I think for the public page we should follow the visitor pref

For the embed widget specifically, following the system preference can clash with a host site that is deliberately the opposite. I lean toward following the system preference there too, because guessing the host page theme is unreliable, but a per-instance override is cheap to add.

For Embed Widgets we should keep light as the default but add a parameter for the developer to switch as required. This way even if they aren't using system prefs and instead using a custom switch mechanism, they can modify the theme themselves. In fact, maybe we should add a parameter to set a completely custom theme for the Embed widget to improve the functionality further