Mel Choyce-Dwan 2:26 pm on October 22, 2020
Tags: bundled-theme ( 83 ), dark mode ( 2 ), twenty-twenty-one ( 7 )

Twenty Twenty-One: Dark Mode Discussion

Yesterday in #core-themes, we discussed Dark Mode support for Twenty Twenty-One. Dark Mode is a setting in some operating systems and browsers that allows individual users to request a “dark” version of the website they’re browsing.

Dark Mode support was added to Twenty Twenty-One during its development phase, and needs testing and refinement during BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. for it to be successful. Unsurprisingly, it’s a pretty complicated feature to wrap one’s head around. There are a lot of conditionals and remaining questions we need to solve.

Dark/Light Toggle

We’ve built in a CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. setting that lets site owners opt their sites out of supporting Dark Mode, for greater design control. Additionally, we’re considering adding a front-end toggle so site viewers can turn Dark Mode on/off, regardless of their OS/Browser preference. This setting would only show if a site allows Dark Mode support.

The idea of a toggle to turn Dark Mode on and off on the user side has been brought up a number of times in issues. There’s currently a PR to explore how it would work in Twenty Twenty-One. Today’s discussion focused around the intersection of this setting, along with the ability to disable Dark Mode entirely.

Dark Mode support is a good accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvement; some folks, for example, enable Dark Mode because they are sensitive to bright lights, or find find dark color schemes less of an eye strain.

We identified five possible scenarios:

Option 1

Allow site owners to disable all dark mode support on their site, regardless of what the user has selected in their OS/browser.
If enabled, allow site viewers to toggle dark mode on/off while viewing the site.
Pros:
- Offers the most balanced amount of control for both site owners and site viewers.
Cons:
- Allows site owners to remove an accessibility feature.

Option 2

Allow site owners to disable all dark mode support on their site, regardless of what the user has selected in their OS/browser.
Don’t allow site viewers to toggle dark mode on/off while viewing the site.
Pros:
- Less visual clutter on the front-end of the site.
Cons:
- Site viewers who prefer Dark Mode might have situations where they’d prefer to toggle Light Mode, and vice-versa; for example, a change in lighting conditions.

Option 3

Don’t allow owners to disable dark mode support.
Allow site viewers to toggle dark mode on/off while viewing the site.
Pros:
- Most amount of flexibility for site viewers.
Cons:
- WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not provide a way to control how sites look in Dark Mode. For example, if you have a dark logo, your logo will be hard to see or even invisible in Dark Mode. There’s no way to add a lighter logo for Dark Mode without using custom CSSCSS Cascading Style Sheets.. Transparent images could face similar visibility issues.

Option 4

Don’t allow owners to disable dark mode support.
Don’t allow site viewers to toggle dark mode on/off while viewing the site.
Pros:
- Least amount of UIUI User interface.
Cons:
- Least amount of flexibility for site owners.
- There are situations where site viewers might prefer the inverse of their default color mode.

Option 5

Don’t support dark mode in the theme at all.
Pros:
- Easiest for us; we revert and boom, we don’t need to tackle the many situations and edge-cases that will arise during Beta.
- No potential conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. between what site viewers see, and what the site owner intends.
- We won’t need to worry about issues like transparent images or dark logos becoming invisible.
- If a site builder is using Dark Mode, they might not realize their site colors are different for most users than what they themselves are seeing for their site.
- WordPress itself doesn’t support Dark Mode yet, so we’re not getting ahead of core.
Cons:
- We’re in a unique position to help support and grow a new web/OS feature.
- We’re also in a unique position to influence best-practice for Dark Mode support within the wider WordPress theme community.

Amongst the folks involved in the discussion, there seemed to be a preference for Option 3, which forced Dark Mode support but allows individual site viewers to toggle it on/off. This late in the game, though, there are also compelling reasons to go with Option 5.

Showing Dark Mode when editing your site

We also talked a little bit about whether or not Dark Mode should be on within wp-adminadmin (and super admin) (specifically, the Customizer and the editor), and whether that front-end toggle should also show within those two admin contexts. This would be useful for site owners who use Dark Mode, so they could easily and quickly toggle it on/off while customizing or creating new content for their site.

Creating a UI control independent of either editor toolbars and metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes within the editor would be a new and unexpected move for a default theme, and would likely create usability and accessibility concerns. Because default themes are used as an example for theme developers, deciding to show the toggle in the editor would require much more discussion from both the default theme team and the Themes team (+make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org//themes). This would have to be outside of the scope of WordPress 5.6.

@sarahricker also suggested that we only ship a proof-of-concept for Dark Mode in 5.6 without the front-end toggle, and then push for native editing of Dark Mode within core for 5.7:

My suggested approach method might be:
Step 1) Proof of concept > theme switches colors based on user’s device
Step 2) In 5.7 – Core adopts support for editing based on user’s device / toggle in backend
Step 3) In 5.7 – TT1 extends POC to integrate with Core AND provides front end toggle

Once core supports being able to customize the design of your site in Dark Mode, we could add that support in to Twenty Twenty-One. We’d also ship the front-end toggle at this time. However, as @williampatton mentioned, default themes rarely get updated with new features after release because of backwards compatibility concerns.

@ryelle suggested that perhaps Step 2 could be more feedback gathering which we push upstream to core and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/:

step 2 would be listening to the feedback & issues we’re finding in TT1, and pushing that feedback to core/gutenberg to get more native support there; and theoretically nothing from a 5.7 TT1 would change except maybe a new “add_theme_support”, things would just work nicer because we have core support

A new add_theme_support to enable a Dark Mode editor for core that allows you to preview and make edits to your site’s Dark Mode styles (maybe something similar to the AMP plugin, but using the Full Site Editing framework?) could be great.

There is a PR adding the front-end toggle in GitHub.

Design tweaks to Dark Mode

We didn’t have a chance to discuss this synchronously, but one other topic I’d like us to consider is making minor design tweaks to improve Dark Mode. I have two issues open which I’d love input on, especially from folks who have Dark Mode enabled on their computers:

Are there any other improvements we can make to Dark Mode which will improve the overall accessibility and usability of the feature?

Videos

Dark Mode in Twenty Twenty-One trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.:

Dark Mode front-end toggle in PR #622:

#bundled-theme, #dark-mode, #twenty-twenty-one

mrwweb 4:51 pm on October 22, 2020
I have an initial preference toward Option 4 upon reading this, but haven’t had a chance to put a ton of thought into it.

I’m mostly commenting on a potential solution for logos in dark mode:
```
@media ( prefers-color-scheme: dark ) {
	.custom-logo-link img {
		filter: invert(100%);
	}
}
```
That would work on everything but IE11 according to caniuse.
- Mel Choyce-Dwan 5:07 pm on October 22, 2020
  
  Could get really weird results if your logo isn’t black & white — for example:
  
  I can see branding issues arise from the sudden drastic change in color.
  - mrwweb 5:18 pm on October 22, 2020
    
    It’s definitely an opinionated change 🙂 I personally like it since it maintains contrast and generally preserves the relationships of colors to each other, but it’s admittedly more of a fail safe. Adding a “Dark Mode Logo” customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. option could maybe accompany this to allow folks to override the behavior.
    - sarahricker 9:15 pm on October 22, 2020
      
      It’s definitely an opinionated change 🙂 I personally like it since it maintains contrast and generally preserves the relationships of colors to each other, but it’s admittedly more of a fail safe. Adding a “Dark Mode Logo” customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. option could maybe accompany this to allow folks to override the behavior.
      
      I agree with @melchoyce that the weird results would be a huge surprise for many with this option enabled by default.
      
      I do however like it as an optional checkbox. Along with that, there could be an info bubble / helper text to explain the risk factor for enabling it. That would give the option until they provided a different logo for the darkmode.
      
      Thanks for the suggestion @mrwweb!
- KZeni 6:48 pm on October 22, 2020
  
  I think Option 1 or 2 (leaning towards 2) is better than option 4 though.
  
  The site adminadmin (and super admin) should have more control over things without needing to go through a whole litany of options to prevent actual problems just for making up for them just not being able to choose their color scheme to always be what they just want (why add an option of toggling the auto-invert of image elements if you don’t want an option just be able to turn off the switching outright?)
  
  I also agree that this auto-invert can really cause issues (both in legibility as well as brand guidelines/requirements). At that point, what about image elements that are just part of the site’s content? Someone might have an image-based icon used in their content that’s all dark. Do we suddenly add a new option to auto-invert all image elements? At that point, we can’t auto-invert all image elements since photos & other aspects shouldn’t then be auto-inverted. I think selectively inverting aspects of a page is really opening a pandora’s box of how do we actually decide what to invert & what not to… and how many options do we then need to add in order to get it so a site admin can get it to be what they want/need (all while considering this could all just be turned into one option of saying whether they want to have it always be light, always be dark, or use the user’s preference [which they can then take into account if they chose that option.])
Kjell Reigstad 4:54 pm on October 22, 2020
I think at first, I lean towards Option 1 (Adding a toggle switch). But a few general thoughts:

As much as I’m a fan of dark mode in general (I use it on all my devices and it definitely helps to reduce eye strain), I think the general public views it as “a thing that apps do” — not something that websites do yet. As mentioned above, this theme could be a step towards changing that perception, but the feature’s novelty is something to keep in mind. Since it will be new and unexpected to many users, we should ensure we explain the feature to users really clearly. Otherwise I expect some tricky scenarios:
- Since folks tend to choose themes based on theme screenshots, I imagine many folks will install it and be very confused about why the theme is purple instead of green. They may think they’ve installed the wrong theme.
- Someone’s in love with their green website, but then they see it on a friend’s (dark mode) phone and think it’s broken.
We could consider making this opt-in instead. That could help. Maybe once coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. fully supports GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, the next default theme has it enabled by default instead.

Aside from that, I have another separate concern that this is a complicated problem to solve during betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. It very drastically changes the look and feel of the front-end, and I don’t believe dark mode was a consideration during the initial design of the theme (@melchoyce, correct me if I’m wrong there). It seems like such an impactful feature deserves a ground-up, intentional approach. That consideration does make me lean a bit towards Option 5 (Removing it for now), though I’d still love to see this added at some point in the future if that path is taken.
- Mel Choyce-Dwan 5:10 pm on October 22, 2020
  
  It very drastically changes the look and feel of the front-end, and I don’t believe dark mode was a consideration during the initial design of the theme (@melchoyce, correct me if I’m wrong there). It seems like such an impactful feature deserves a ground-up, intentional approach.
  
  Yeah, it was a later addition. Seemed like a good opportunity to explore, but ideally I would have really intentionally designed Dark Mode before development started. I love the idea, but my suggestions have been really reactive so far, not proactive.
Joy 6:24 pm on October 22, 2020

A new add_theme_support to enable a Dark Mode editor

This page: https://developer.wordpress.org/block-editor/developers/themes/theme-support/
talks about Dark Mode, and has add_theme_support( 'dark-editor-style' ); so you probably should get the language around this consistent.

I don’t think it should be the theme’s responsibility to supply the toggle, whether that is in the adminadmin (and super admin) or the front end. CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. should invoke the theme’s “support” that the theme opts in to, when the core-supplied toggle is used.

I thought perhaps you could use mix-blend-mode for the images, but looking at https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode I’m not so sure.
Stephen Bernhardt 6:29 pm on October 22, 2020

If adding a toggle switch to the adminadmin (and super admin), I recommend making it more like agreeing to terms: “I want to activate dark mode and will verify that my content works well in both light and dark.” Or perhaps activation could require use of a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, at least for now.

Dark mode is not always more accessible. If someone uses a custom text color even once in one post, good contrast against the light background is likely inadequate against the dark. Some images with transparency would not accommodate both modes. Custom color palettes and other features might cause other difficulties. So an admin option would require a commitment.

On the other hand, if a visitor toggles dark mode on but the site either lacks sufficient support or it simply looks unappealing, the individual user could turn it off again (as long as the switch is still recognizable). A front-end toggle also lets visitors who normally prefer one way determine whether a certain site is better the other way.
KZeni 6:42 pm on October 22, 2020

Options 1 or 2 sound like the best way to go.

For option 1, I don’t think the con that’s mentioned there makes much of an impact when it’s regarding disabling something that previously didn’t even exist (with those that need a scheme for accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) already having other means of applying it [per the countless sites out there that don’t have a light/dark mode toggle built-in) while it helps ensure things like logos, graphics, & other static elements then don’t conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with a possible light/dark mode variant if they then didn’t know to / have the time to account for both. Even if you do an invert on images & other static elements via CSSCSS Cascading Style Sheets.… that could then break photography that might come into play, have it breaking brand guidelines/requirements (possibly for brands that are just present on the site who might take real issue with their mis-representation, etc.) I really do think site owners should be able to say it’s always light, always dark, or uses the user’s preference (“auto”).

For option 2, again, the site adminadmin (and super admin) should have control over their site… but then the visitor has already made a preference to whether they want light or dark mode to be shown per the `prefers-color-scheme` media query so we then don’t need to clutter up the visitor’s experience (again, considering they’ve already set their system to specifically be light/dark/auto & this is just software following-suit.) I mean, macOS has this option which websites can follow for determining light/dark mode while native apps default to just showing what that preference is (unless the app is advanced enough where users care enough to make it something other than the default to then introduce a setting for them.)

In short, I could definitely see “Light”, “Dark”, “Auto” be shown as an option in the theme settings for admins (light and dark being hard-set so it’s that all the time while “auto” has it follow the visitor’s preference/current situation). Meanwhile, I’m not 100% certain on whether there should be that same option presented to the visitor for their needs/preferences (Stack Overflow & others have this), but others don’t (many native apps on macOS, assorted sites that don’t want needless settings presented to their visitors just cluttering things up when the user has already stated their preference of dark/light/auto in their system to get there, etc.) Maybe showing the option of the light/dark/auto to the visitor could be a second theme setting if/when the site admin chooses the “auto” option (per it not forcing dark or light all the time for whatever their wants/needs are as the site owner/operator.)
- KZeni 6:51 pm on October 22, 2020
  
  An Option 6 might need to be added for consideration where the site adminadmin (and super admin) has the always light/always dark/auto (use visitor’s preference setting) which then has a second option shown if the auto option is selected which then has the visitor-facing toggle shown or not (possibly being a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. rather than a setting as an option 6b if a second setting that’s conditional is then adding too much in the site admin settings.)
Jeff Ong 9:37 pm on October 22, 2020

Under options 1 and 2, will dark mode be enabled by default?

Since it’s a rather experimental and may break site admins and visitors expectations, I think it should be opt-in.

Option 2 seems the most straightforward thing to support initially while it’s worked on in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. / GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.
- Jeff Ong 9:42 pm on October 22, 2020
  
  Ah I see @sarahricker mentioned opting-in already, I second her comment!
  - sarahricker 9:43 pm on October 22, 2020
    
    Woo! 🙂
scruffian 9:49 pm on October 22, 2020

I can’t see much benefit to allowing site visitors to toggle the setting; their preference is already set at system level, and they can change it there. In any case I think the vast majority of users would be unaware that there was an alternative.
Helen Hou-Sandi 10:42 pm on October 22, 2020

I have tried and failed to write some kind of novel for the past bit so just going to give up and post a couple disjointed thoughts instead.

My tl;dr: is that my instinct right now is that it would be best to split dark mode for TT1 out into a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party as a form of opt-in, primarily because I think that will both ease the burden for meeting the bar for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ship and also gives space for the feature to be iterated on outside of the core development cycle, especially because I think as people use the theme they’ll be doing things with it we haven’t/can’t anticipate and a plugin can actually respond to those changing needs. By separating it out, I think it has a better chance of reaching a point where it encompasses enough by default to be a theme setting without too much futzing on the user’s part, or even enough of a thing to be a feature for all themes at large.

When testing TT1 locally, I was very confused about what was happening to my experience because it started out dark, I changed the color to something I liked, but then when I changed other settings it reverted the color again and I didn’t understand what was going on even though there’s a little banner about “previewing” the color in dark mode. That felt like a very strange experience to me, and still does even though I expect it.

I think because we’re not yet accustomed to dark mode on sites (easier to understand in the context of app UIUI User interface) I don’t really map that concept into how I customize a theme, and would also be very confused if I was setting my theme up to be kinda dark anyway. Does that mean that then I don’t have a light theme? Do I understand that a dark theme is only a value-add if I’m making my site some definition of “light”? I always like the idea of WordPress being able to be a part of something new-ish gaining traction but I think we might a bit early for dark mode websites.

I do use dark mode myself across desktop and mobile, however some apps (and now sites) work better for me in light mode, or I like having differentiators, so as a user I always appreciate a toggle 🙂
- mrwweb 10:59 pm on October 22, 2020
  
  Everything here makes tons of sense.
- Helen Hou-Sandi 3:46 am on October 24, 2020
  
  I asked about a web property we work on with dark mode and their user toggle usage is vanishingly small even with a readership that is savvy about things like that, so while I personally am one of those people who likes a toggle it’s probably not worth the effort to have one that displays universally well and wanders into personalized data issues 🙂
Stefan Kremer (stk_jj) 2:15 pm on October 23, 2020

I would love to add another aspect which seems not yet discussed here: privacy issues with cookies … let me explain:

If a user get’s the choice of dark mode on/off it can be first of all just for this very session (stored in a session id, no harm done). But: At least when you want to make this choice permanent (e.g. visiting that page next time the setting for dark mode is persitant) it would surely done by the use of a cookie.

Which has some implications in Germany (I’m not aware of legal impacts in other countries, but as far as I know in general it implies more or less in other EU countries as well). There’s consent needed to set such a cookie, which at the moment can only be properly done with 3rd party tools (e.g. Borlabs Cookies).

The very minimum to do would be to add an additional notice within the privacy reader to make users aware that they have to act when making use of this feature of allowing their website visitors to chose dark mode or not.
- Ari Stathopoulos 2:20 pm on October 23, 2020
  
  it would surely done by the use of a cookie.
  
  No cookie is used. If you check the code on https://github.com/WordPress/twentytwentyone/pull/622/files#diff-6053423ae27b84399d72dee15328f2612ae620aba87844ba65ab70a1aaae273e you’ll see that it uses localStorage. There are no privacy implications with that. It only stores “yes”/”no”, and is only accessible on the current site.
  No consent is needed, nothing gets sent anywhere or is accessible by anyone.
- Bernhard Kau 2:52 pm on October 23, 2020
  As I worked on some tickets regarding dark background colors and some default blocks, I would say that having an option to set a dark background-color and having all elements show up with a good contrast color would be amazing.
  
  I do think that site owners should actively “opt-in” to dark mode by setting one explicitly. I could see an options like this in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. at “Colors”:
  - Toggle: Activate/Allow Dark Mode
  - If “Off” (default)
  – Background Control
  - If “On”
  – Background Control (Light)
  – Background Control (Dark)
  
  If we add a functionality to show a Light/Dark Mode toggle to the frontend, the site owner should also be able to set a “Default background color / color scheme” in the Customizer.
  
  I’d really like to see TT1 provide a CSSCSS Cascading Style Sheets. file for a Dark Mode using the CSS `prefers-color-scheme` method. A toggle would be something that (CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.) could add later or a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party could add.
Mel Choyce-Dwan 4:18 pm on October 23, 2020

Added videos to the main post.
Nick Halsey 6:10 pm on October 25, 2020

I prefer option 3, with the front-end toggle defaulting to the user’s device/browser-specified preference. This toggle would be functional within the customize preview and editor post contextual previews to allow site and content authors to preview both modes.

I would also support a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. option to include a dark mode site logo option. The vast majority of other images, such as used in content areas, will not have transparent backgrounds. Anecdotally, my Figure/Ground theme dynamically inverts light/dark on alternating posts; I have not seen any instances where this leads to legibility issues. If there are any content visibility issues, the front end toggle allows any content visibility issues to be worked around.
Mel Choyce-Dwan 10:09 pm on October 26, 2020

Update:

Based on all of the discussion in this thread, @poena and I made the decision to move Dark Mode out into a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. This will allow us to better address all of the edge cases we’ve been encountering without slowing down the progress of bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixing within the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. theme. Without the stress of the RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). deadline, we’ll be able to do a better job finding the best approach to supporting Dark Mode.

@aristath has migrated the feature to here: https://github.com/wordpress/twentytwentyone-dark-mode

If you’re interested, please check it out, test, and add suggestions!