Native support for dark mode (front end)

[mpwrdesign]

With most mobile devices and many computers supporting a native dark mode, it is important for WordPress to consider adopting the feature. At WWDC 2019, Apple outlined a ​method for implementing dark mode into web content. In order for WordPress to properly and completely support dark mode, the following would need to occur:

• Code should be included in WordPress core to detect whether a device is using light mode or dark mode (as outlined in the link above)
• The Customizer would need to include color pickers for light and dark colors for every element
• The Media Gallery would need to support light and dark images, with the proper one loaded depending on the device state
• New functions would need to be created to allow plugin and theme developers to specify light and dark colors and images on themes and plugins

Supporting dark mode properly will be a major undertaking, but due to the rapid rate at which devices and apps are supporting it, I believe this should be a priority for WordPress later this year, perhaps as soon as 5.6.

[SergeyBiryukov]

Previously: #41928, ​Merge Proposal: Dark Mode.

[mpwrdesign]

Replying to SergeyBiryukov:

Previously: #41928, ​Merge Proposal: Dark Mode.

Sergey,
This is a separate request from #41928. That ticket refers to implementing dark mode into the WordPress Dashboard. This request refers to implementing dark mode on a website’s front end.

[sabernhardt]

The video describes 4 methods, summarized as:

1. Use color-scheme [property] to declare support
2. Adopt prefers-color-scheme media query
3. Use <picture> for hero graphics
4. Consider using var() for color schemes

Adding the first two methods on the front end would mean individual themes create both light and dark modes. Using something like add_theme_support( 'light-dark-modes' ) might be part of the process. Also note: some themes already work well as dark-only.

The <picture> tag method would need editor and/or media support if adding multiple versions of an image to the content area. Other images for consideration include featured images and maybe the site logo.

It's a little soon for many sites to use the CSS variable method exclusively; that would need a fallback for Internet Explorer and other old browsers. Also, the block editor's editor-color-palette does not allow variables yet (#46498), though the palettes would need to start supporting multiple selections for multiple schemes even with the current hexadecimal color codes.

I use dark mode on my laptop and would appreciate more sites acknowledging the preference. However, the major barrier to implementing dark mode is not technical. Site administrators and editors would need to be aware of the two modes and verify all content will work in both before publishing.

[afercia]

This ticket was discussed during today's accessibility bug-scrub. While it appears there are some parts that would involve changes in the admin, those would be necessary to implement a themes feature. Changing the component accordingly.

Maybe a good start would be a feature plugin?

[jorbin]

This feels like theme territory to me. Can someone explain how this could be built in a theme agnostic way?

[knutsp]

As for any "mode" on the front end, it be screen size, accessibility, color blind, dark, light, black & white, green, blue, yellow mode, or whatever, what is the problem for a theme to implement such modes, for front itself and what is needed in admin?

A theme supports array that indicates what modes it supports, then this enables the admin user to supply images and such in up to all those modes? Remember that the customizer, as options pages, are controlled by the theme.

For core to implement things, modes and languages as an example, the need for standardization must be quite clear. So that modes from one theme by be valid in another. Like post formats was intended to. Need a limited set of of modes, extendible only by core. 'dark' and 'default' could be a start.

Something to develop in cooperation with a "Twenty Twentyone" team?

[critterverse]

We discussed this ticket in the weekly bug scrub in the #accessibility channel on the Making WordPress Slack. Some concerns came up about the feasibility of implementing Dark Mode natively in a reliable manner:

​https://wordpress.slack.com/archives/C02RP4X03/p1617378616368100

To summarize the conversation:

• It's questionable how much core is needed, maybe most of the work can be done in themes
• However there is interest in native support among some in the Design group
• There are plugins that attempt this feature but it's difficult to do it well/completely (due to not being able to identify everything in a theme that needs to be recolored)
• Questions around how this could work — potentially a Dark Mode toggle that would override all colors in theme and plugin stylesheets?
• There would be a big documentation aspect in terms of teaching users how to implement Dark Mode into their themes to work with the core Dark Mode feature

[joedolson]

After discussing this in another accessibility meeting, we're going to stop tracking this issue unless there's outside movement. Our opinion is that this feature would be outside of core scope, and is best implemented at the theme or site level. However, there may be some features that core could implement to make setting up dark mode easier - but implementing a fully configured dark mode within core isn't really practical.