Twenty Twenty One: Consider disabling darkmode in wp-admin

[Clorith]

Darkmode is a front-end feature of the Twenty Twenty-One theme, which lets a user toggle their viewing preferences.

With this, some unexpected side-effects have come up within wp-admin (see for example #53525, #53429).

Would it perhaps make more sense to not load dark-mode styles and features from the theme within the constraints of wp-admin? Some quick testing shows that this is a simple implementation case, achieved by adding an is_admin() check to the Twenty_Twenty_One_Dark_Mode::switch_should_render() check, and returning false if it is an admin screen.

Although the theme was introduced with WordPress 5.6, and some of the style-bleeding was present then as well, it is more apparent with the new widget editor, where the darkmode toggle button renders in each legacy widget (which all widgets are considered when first loaded by the block editor for widgets), and it's styles can have unexpected effects on the site, depending on user settings, as seen in the previously mentioned #53429.

Adding to the 5.8 milestone for consideration, on the grounds of the block-widget editor surfacing this issue more broadly.

[poena]

If I understand the referenced tickets correctly the problem is not with the darkmode code, but that the widget screen previews doesn't have a CSS class to identify it with?

Then disabling the dark mode for all editors does not seem like the best choice.

The widget screen should be fixed. The Twenty Twenty-One theme will not be the only theme to style this area.

[Clorith]

It's more about the inconsistency in how it is being applied, since it's bleeding into controllers as well (see #53525 where it's affecting the block inserter for example, the same affects the inserter in the customizer).

You are right that other themes may also style the editor, and that isn't a problem, the general styling works great in Twenty Twenty-One as well, it's only the dark mode here that affects too broadly because the reference element classes do not exist (and probably shouldn't exist) widely inside the admin area.

[poena]

There still needs to be a way to identify exactly which screen is the current screen.

That way should be used to either correct the problem or turn it off temporary for specific screens.

Major features should not need to be removed for the entire admin area because two screens were added without identifiers.

[JeffPaul]

With no clearly agreed to approach here, no patch/PR, and no clear owner I'm going to punt to Future Release though hopefully this can be addressed and get into 5.8.1 or 5.9.

[poena]

I believe the dark mode issue on the widget screen and inserter have been solved,
are there any additional dark mode issues reported?

[karmatosed]

This looks like it has had enough time for now to get feedback and I am going to follow through on @poena's recommendation to close. It was marked for punt over 3 years ago and 21 months ago the issue noted as solved. As no further issues have been reported it looks like for now we can close this. If however, we do get more issues this absolutely can either reopen or a new issue be focused on.

Thank you everyone for collaborating on this.