Here are the CSS variables on the homepage of my test instance, when ‘dark’ mode has been enabled under user preferences.
Here are the CSS variables on the homepage of my instance, when a ‘dark’ theme has been specified for the forum.
Here are the CSS variables on a new wizard I have created with no theme set (this is the same regardless of the theme selected for the whole forum, or the user’s dark mode preference):
Reproduction Steps:
Enable ‘dark’ mode under user preferences or pick a dark color scheme for the discourse instance
Firstly, this one is not a bug as there is a seperation between wizard and discourse themes, and the Custom Wizard Plugin has never supported theme swtiching (I’ve recategorised it). The CSS of wizards is different from the main Discourse app (indeed the wizard is an entirely seperate Ember app). When a user is selecting the “Dark” theme (or any other theme, theme swtiching is not just for light / dark) in their preferences, they are selecting a different theme for the Discourse client, with all the different assets of that theme color scheme, css, javascripts, theme components etc, not for the wizard client.
That said, I understand why this feels “unexpected”, and it’s something that I’ve considered off and on for some time for this reason. I took another dive into the discourse theming system and there is now a more straightforward way to seperate out the “color schemes” of different themes for the discourse client. I’ve tweaked the handling of wizard themes to use the color scheme associated with different themes selected for the discourse client as a base. Happily, a simple update.
This means that if a user selects a different theme in their user preferences, the color scheme associated with that theme (and nothing else in the theme) will be applied to the wizard via the :root variables. I think this is the expected outcome you’re pointing at in this report. And this will probably align with others’ expectations.