Discussion: `prefers-color-scheme` media-query

[aristath]

We start seeing more and more sites implement the prefers-color-scheme media-query in the web. And that's really an awesome thing since they respect the user's preferences on the OS level.
However, such a thing is currently not possible in Gutenberg because of block-level color settings.

Themes can implement that media-query and change the overall background - and text - colors for the whole page, but if an author sets the background-color of a block to white for example, then users who prefer a dark scheme (for a11y reasons or even plain preference) won't get what they want/need/expect for that block.

This s currently not an issue because no themes (that I am aware of) support the media-query properly. But part of the reason why they don't is that Gutenberg won't allow them to... The issue is very pronounced in case the theme switches colors for the whole page because then any blocks with a defined background-color seem out of place.

One option would be to somehow detect that a theme supports the prefers-color-scheme media-query (possibly via a theme_supports( 'prefer-color-scheme' )), and if it does then provide 2 sets of color options: One for light and one for dark (maybe tabbed?)

Users would then be able to edit color options for both modes.

On the generated HTML, css-vars could be used to declare all properties, so we'd have something like

<p class="has-background has-text-color" style="--bg-dark:#000;--bg-light:#fff;--color-light:#000;--color-dark:#fff;"></p>

The CSS would then look something like this:

p.has-background {
	background-color: var(--bg-light);
}
p.has-text-color {
	color: var(--color-light);
}

@media (prefers-color-scheme: dark) {
	p.has-background {
		background-color: var(--bg-dark);
	}
	p.has-text-color {
		color: var(--color-dark);
	}
}

Another option would be to only provide a single set of options (like we do now), but save 2. That could be accomplished by detecting which mode the editor is using while selecting the colors (dark/light), and from that extrapolate both modes. So if I'm on light mode and select for example #f2f2f2 for a block's background color, then a dark color could be auto-calculated by checking the luminance difference between my selected color and white, then find a dark color that has the same lum-diff from black (in this case that would be #111111.

Both options have their pros and cons... and perhaps both can be used at the same time. The way I envision it, if a theme supports color-schemes, the "missing" one would be auto-calculated, and if users want they'd be able to define their own custom colors for both schemes.

[youknowriad]

This is interesting and I can see how it can be useful to support dark mode. I think for me instead of starting at the block level like suggested above, another approach could be to build this on top of the theme.json work being done at the moment.

One of the heuristics used there to define: palettes, default colors globally or per block could be the dark/light mode.

[youknowriad]

To clarify more, the theme.json could be:

{
   presets: { global: { color: { light: [] dark: [] }   } },
   style: {
       global: {
           light: { color: black },
           dark: { color: black },
       }
     }
}

of course this is just pseudo-code to get the idea.

[aristath]

I like the idea of having it in theme.json a lot! It makes perfect sense to have it there.
However, that's just for the presets, right? So the question is, how would users be able to control these from the UI?
We could for example add a light/dark switch and allow them to select separate values per-color-scheme... If they don't, then we fallback to defaults. But where do we add the light/dark switch? 😅

[youknowriad]

However, that's just for the presets, right? So the question is, how would users be able to control these from the UI?

I think it's more important for theme than the user for a start but I agree that having in both is better specially with FSE generating the theme.json configs. the theme.json is also used to set the default colors but yes, we need something in the UI as well if we want these to be editable there.

If they don't, then we fallback to defaults. But where do we add the light/dark switch?

Yes, very hard to get it right, with all the potential options and combinations. Let's add a design label to get some thoughts.

[paaljoachim]

Here is @ItsJonQ 's Design Tools issue:
#24341
As I believe down the road that it will handle the UI side of switching between dark/light color schemes.