Opened 4 years ago
Last modified 4 years ago
#51656 new enhancement
add_theme_support() for 'wp-dark-theme' so plugins can use consistent CSS for dark themes
Reported by: | mpol | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description
As a plugin developer I sometimes have to write CSS for the frontend for one of my plugins. When I do need to do that, I try to write CSS that fits most themes, like light-grey colors. When a website has a theme with dark colors activated, these light colors do not fit it and it can give a bit of a jarring experience, that deteriorates the idea of that dark theme.
I will attach a screenshot with the dark theme 'minimal-dark' and the plugin 'gwolle-gb'. You can see a black frontend page and a box from the plugin with light colors.
I think it would be good if there is a body-class for themes to use where they can declare that they are a theme with dark colors. Plugins can then provide some dark-theme CSS for elements. When themes and plugins all use the same consistent body-class it can be a useful feature.
Please be aware that this is a different ticket than #50051 which is much wider in scope, where the setting of the browser (or desktop) will make themes switch to a dark mode.
This one is about a body-class that would be a way for theme developers to communicate to plugin developers that it is a dark theme and needs dark-colored CSS.
Also, this is not about form elements like buttons. I strongly believe styling of form elements is up to the theme.
I am willing to provide a patch.
I can imagine adding support for it in 'get_body_class()' and a comment update in 'add_theme_support()' would be enough. I tested this already.
I propose 'dark-theme' as parameter, where the 'wp-dark-theme' gets added as a body-class, just to avoid conflict with third-party solutions. Also to make clear this is not about a dark-mode for browsers.
Attachments (2)
Change History (7)
#1
@
4 years ago
I think plugins shouldn't have CSS with colors, and it would work with any theme.
If you insist on adding this, don't make it theme_support, like the already existing one for the editor: https://developer.wordpress.org/block-editor/developers/themes/theme-support/#dark-backgrounds
It also can tie in with the dark mode(prefers_color_scheme(dark)), which should inform the theme of the change, not the theme informing everyone else, since that is a user choice. There are so many themes which allow the user to choose both foreground and background colors, so the theme doesn't really even know when it's in dark mode.
Or maybe the existing add_theme_support should take two colors supplied by the theme, and there is a core function like is_dark()
that defaults to false but checks the colors for darker than some middle gray or something. I think having a centralized place for the calculation would help everyone get it right more often.
#2
@
4 years ago
This ticket and patch are mostly aimed at being able to support dark themes that are only dark theme. I can imagine themes with custom colors can be supported by checking for a dark background, like you propose. That might be iterated on I might think.
And yes, it can tie in with that other ticket #50051 about dark mode. If the browser requests it, the theme switches to dark mode, and adds theme support. This ticket is about that last step then, which then also communicates to plugins that it is a dark theme through the body-class. That way by simply targeting that body-class, plugins are consistent with the dark theme and the dark mode.
I am not familiar with the Gutenberg Editor and could not find anything specific on that link you provided.
#3
@
4 years ago
Tickets should document a problem, and then there can be discussion about what makes a good solution.
It sounds as though you are only looking at one aspect of it, and that aspect can be avoided by not using colors at all in the plugin CSS, so the solution is a bit strange.
#4
@
4 years ago
You have a point, I am already set on a solution :)
I do think I did describe the problem, and people can always propose a solution.
I do think that it is not always avoidable to use colors in plugin CSS. I try really hard to use as little CSS as possible, but sometimes it does seem to be necessary.
Then I often see (through support requests) websites with a dark theme where the plugin CSS doesn't fit the styling of the theme.
#5
@
4 years ago
I happen to have authored a theme where the user can choose whatever color they want, so my theme would have a difficult time with dark mode or your proposed theme_support field. It also allows the user to easily swap foreground and background on various elements like sidebar or widgets (or wherever they put the class). So even if I do analyze the background color to determine dark or light, they could have swapped it on #main
or #content
and so the analysis is moot. Adding an inaccurate body class won't solve your problem, and it should work without the theme having to do anything or it will be forever until adopted.
If your concern is about things like <select>
being the "correct" color, it seems that you have tested with themes that don't style everything. My theme styles <select>
, and it all matched until a recent update to Firefox that made my styles not work.
screenshot with the dark theme 'minimal-dark' and the plugin 'gwolle-gb'. You can see a black frontend page and a box from the plugin with light colors.