I have been considering this option for a while now, and I'm glad to see there is demand for it and that you decided to implement this already. I do think this is a complex feature, because not all would want this, so there should indeed be separate light and dark themes, which you took care of nicely. On the other hand, I am not sure about the approach of replacing default with dark for internal code. Shouldn't the theme be reflected in these parts too? Usually the entire reason the default css is loaded is to apply the default colors, which are then possibly overridden by the active theme. So if we change the default theme to adapt to light and dark, I expect the interface to do so in all places, unless I'm missing some issues with this reasoning you encountered while implementing. Overall, I'm glad there's development on this, we can discuss it further here before we decide to merge this in, which will only happen when I start working on the v13 branch anyway, as this is definitely a breaking change.

On the other hand, I am not sure about the approach of replacing default with dark for internal code. Shouldn't the theme be reflected in these parts too? Usually the entire reason the default css is loaded is to apply the default colors, which are then possibly overridden by the active theme.

My intention was to maintain the logic which makes other colorschemes inherit from the default one, since now it has changed to dark.css from default.css, I just don't know where to look for due to my limited understanding of javascript.
I do intend for the Vieb pages to use the new dynamic default.css theme.
The latest push should address that by having the would be dark.css go back to being default.css to maintain the inheritance logic until I understand how to alter it, and having the new default.css be new-default.css.

Since this would only be merged as a breaking change anyway in the upcoming v13 branch, I don't mind having only an updated default.css, not a new-default. So basically: I would prefer this PR to show me the ideal end-state diff without migrations or handling of existing features, merely changing the defaults to do this, and have separate themes dark/light that don't.

Assuming I understood correctly, with this latest push there’s only one hurdle left: the stylesheet loaded by default for Vieb pages is the same one that other colorschemes inherit from—namely dark.css, since it now contains the base CSS rules previously found in default.css.

To fix this, I just need to figure out how to manually trigger the loading of default.css (as if colorscheme default were set in the viebrc) from an appropriate place in the javascript.

Currently there is still a lot of code moved from default to dark, and as such to any other built-in theme using these colors. Ideally only the default.css file should be have a lot of changes to achieve this functionality, and have it affect all places as a result automatically. A new dark theme and the current light theme should then simply undo the automatic switching and probably not have much other styling in there. As well as there being little to no changes needed to other themes.

I moved automatic switching into default.css and made dark.css (and all dark- colorschemes) override with the dark colors which undoes it. Now it all works correctly.
I wanted to ask, is the date on the copyright notices for the new theme variants correct?