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

[KitKat31337]

Honestly this might include actual theme support as well. Right now I am using the tracking code field to inject my custom CSS to theme my booking pages.

[shockalotti]

That is a useful data point, and it argues for doing this sooner than the rest of the thread implies.

Injecting CSS through the tracking code field to theme a booking page is exactly the shape of a feature gap being worked around, and it has two costs. It is per-instance, so it has to be redone on every deployment and nobody inheriting the instance knows why the field is full of CSS. And it means the tracking field cannot be trusted to contain tracking, which is a problem the moment anyone audits what is running on the public pages.

So I would treat theming as part of the dark mode work rather than a separate idea, because they are the same underlying problem: booking.css has no semantic variables, so neither a dark mode nor an operator theme has anywhere to plug in. Converting that file to variables is the shared prerequisite. Once it exists, dark mode is one override block and a custom theme is another, and the tracking field goes back to being tracking.

No timeline, but the ordering is worth writing down so the CSS conversion is not treated as dark-mode-only work and then partly redone later.