Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#50051 closed feature request (maybelater)

Native support for dark mode (front end)

Reported by: mpwrdesign's profile mpwrdesign Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Themes Keywords:
Focuses: ui, accessibility Cc:


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.

Change History (16)

#1 @SergeyBiryukov
4 years ago

  • Focuses accessibility added

#3 in reply to: ↑ 2 @mpwrdesign
4 years ago

Replying to SergeyBiryukov:

Previously: #41928, Merge Proposal: Dark Mode.

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.

#4 @sabernhardt
4 years ago

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.

#5 @afercia
4 years ago

  • Summary changed from Native support for dark mode to Native support for dark mode (front end)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#7 @afercia
4 years ago

  • Component changed from General to Themes

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?

#8 @jorbin
4 years ago

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

#9 @knutsp
4 years ago

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?

This ticket was mentioned in Slack in #core-css by notlaura. View the logs.

4 years ago

This ticket was mentioned in Slack in #core by sergey. View the logs.

3 years ago

This ticket was mentioned in Slack in #accessibility by alexstine. View the logs.

3 years ago

#13 @critterverse
3 years ago

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:

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

This ticket was mentioned in Slack in #accessibility by critterverse. View the logs.

3 years ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.

3 years ago

#16 @joedolson
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.