As a follow-up of both #3606655: Make dark mode a first class citizen of Drupal core and #3517033: Add a style utility API.
Problem/Motivation
The Style API is managing both style utilities and themes ("themes" as design system themes, not as Drupal themes) and each theme option can be annotated with one of those 3 enums:
color_scheme: withlight&dark. See https://developer.mozilla.org/fr/docs/Web/CSS/Reference/At-rules/@media/...contrast: withmoreandless. See https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@med...reduce_motion: with onlyreducefor now. See https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@med...
No logic is related to those annotations.... yet.
In the other hand, #3606655: Make dark mode a first class citizen of Drupal core has added some logic between light/dark modes in themes ("themes" as Drupal themes, this time, not necessary as design system themes) and user preferences, with some drawbacks:
- only color_scheme mode is supported
- there is a coupling between a mode and its implementations, which is wrong because many design systems don't do that. For example, Daisy UI has many themes: https://daisyui.com/docs/themes/, some are suitable for light mode, some for dark modes:
- cupcake: light
- synthwave: dark
- corporate: light
- pastel: light
- coffee: dark
- ...
- the data attribute and the HTML targets are hardcoded:
<html data-color-scheme="dark">, but many way of adding such information exist:data-bs-themeattribute, anywhere, in https://getbootstrap.com/docs/5.3/customize/color-modes/#dark-modedata-themeattribute in https://daisyui.com/docs/themes/data-fr-schemeattribute, only inhtmlelement, in DSFR- sometimes it is not a data attribute but a class or a meta element...
- sometimes this attribute can be placed anywhere to have "scoped" theme switches...
Can we conciliate the two?
Proposed resolution
Add a default_admin.styles.yml file:
color_scheme:
attribute: "data-color-scheme"
target: html
type: theme
options:
light:
label: "Light"
modes: {color: light}
dark:
label: "Dark"
modes: {color: dark}
This may make supports color scheme: true from info.yml redundant. Do we keep it?
Add a mechanism to map those themes to the modes we want to expose to the user settings. Here is a mockup to explain the mechanism (we are not sure this ticket will have a proper UX proposal):

Connect the new API from #3606655: Make dark mode a first class citizen of Drupal core (\Drupal\Core\Theme\ColorSchemeSupport service and others) to the Style API. If possible, prepare the user settings parts of this API for other modes than color_scheme.
Remaining tasks
TBD
User interface changes
Probably not.
API changes
Style API will be extended a bit. But the main changes will be to articulate 2 existing APIs, without extending much.
Data model changes
Probably not.
Release notes snippet
TBD
Comments
Comment #2
kentr commentedComment #3
pdureau commentedThanks you for opening this issue.
Ping @grimrepaer
Comment #4
pdureau commentedDescription update.