Modern OSes and browsers can now report a user's preference for a "dark mode" setting. See https://css-tricks.com/a-complete-guide-to-dark-mode-on-the-web/ for some background on technical specifics.

The default IkiWiki anti-theme leaves most styling decisions up to the browser. Nevertheless, the anti-theme will always be rendered as Light, regardless of a user's preference for dark-mode, as a site's css needs to explicitly indicate that it can support dark-mode in order for it to be available.

IkiWiki's anti-theme almost entirely supports dark-mode out of the box by virtue of delegating the style decisions to browser defaults. We should add the minimum required CSS to let it be enabled.

(The only example of default theme which does not appear to look good in dark mode, in my testing, is the styling around RecentChanges.)

—­Jon, 2022-12-12

more work is needed before this should be considered. For the anti-theme, several plugins and features have CSS with hardcoded color values that might not make sense in a dark mode: some are easy to fix (any border: black can have the color spec removed; black is the default in light-mode, and a better choice will be made for dark-mode) but others will require more work (recentchanges and changelog force black-on-white with !important, and before removing that I need to answer why).

Then we get onto the themes supplied by IkiWiki: they will need surveying since they will inherit the settings from doc/style.css.

And finally we should think about the impact this would have on downstream users and custom themes not supplied in IkiWiki; at the very least we would need to be clear in release notes that this might be a problem, and how to avoid it.

— Jon, 2024-02-26

closing (done) in favour of the approach outlined in support for light and dark mode. — Jon, 2024-XX-XX