Support for light/dark theme from system setting

[lukasolson]

Describe the feature:

Currently, an advanced setting theme:darkMode controls whether you see Kibana in light or dark mode.

Instead of having a simple toggle (dark mode on/off), it'd really be nice if there were three options: Light mode, dark mode, or browser setting (similar to how we do timezones). It'd be especially nice for those Mac users who have the preference set to "auto" so it changes based on the time of day automatically :)

Most modern browsers support inferring the user's preference via window.matchMedia('(prefers-color-scheme: dark)') (or light).

[elasticmachine]

Pinging @elastic/kibana-design (Team:Kibana-Design)

[knechtionscoding]

Also, having this be a user specific setting. Having to set it for an entire space is clunky and very odd compared to most other implementations.

[pgayvallet]

Tentatively assigning for on-week

[pgayvallet]

So, I was able to develop a POC within a day.

I was hoping to simply get away by moving the css files "logic" from the server-side rendering service to somewhere in the UI side (by sending the list of css files for each theme to the browser) and add a third system option for theme:darkMode.

It worked fairly well on the advanced settings page, even for dynamic theme switching, which was very encouraging.

Screen.Recording.2023-12-11.at.13.25.59.mov

Then I started navigating though the site, and observed some strange behavior in most pages:

Screen.Recording.2023-12-11.at.20.34.52.mov

This is when I started to suspect that some things were still using "static" versions of some of their styles, that would be loaded only once or something.

The first obvious one was the inline styles that we are using for the global loader:

kibana/packages/core/rendering/core-rendering-server-internal/src/views/styles.tsx

Lines 27 to 30 in 243d36c

	const InlineStyles: FC<{ darkMode: boolean }> = ({ darkMode }) => {
	/* eslint-disable react/no-danger */
	return (
	<style

The second one are the plugins scss files and the way we're loading them.

For example, we have a component importing a sass file:

kibana/src/plugins/controls/public/control_group/component/control_group_component.tsx

Line 9 in f1dc1e1

import '../control_group.scss';

and then the sass file using an eui varible that depends on the theme:

kibana/src/plugins/controls/public/control_group/control_group.scss

Lines 107 to 110 in bafb235

	.controlFrame__control {
	height: 100%;
	transition: opacity .1s;
	background-color: $euiFormBackgroundColor !important;

Under the hood, our optimizer / bundler is looking at the window.__kbnThemeTag__ variable to determine which theme should be used for variable interpolation for sass files.

However, once the component/themed-css file is loaded, dynamically switching without a page reload doesn't reload the css (as it does for the new EUI theme provided based on Emotion/jss)

TLDR:

• applying system theme during page load mostly (fully?) works
• changing the theme after initial page load cause glitches (so it should probably be disabled or moved being another setting)
• still need to figure out what to do with inline styles used for the loading screen

[pgayvallet]

So, the PR is ready: #173044, however during development of the PR we discovered this issue: #173529 which seems to be a blocker for this feature.

[legrego]

Not a blocker, but it would be great for us to have a plan for #155945 before merging, too. Otherwise, we'll have a confusing feature gap between the two systems.

[pgayvallet]

@legrego I created #173895 to discuss how to close this feature gap.