Replace color module with a CSS-Variables based module to provide configurable theme parameters

Off-hand this sounds like it might be a great solution technically... is it possible to upload some screenshots of the module (either here or to the project page or both) so we can get an idea of what the end user experience would be?

Over the last couple of days we worked intensively to make cssvars work with ie11. We're using css-vars-ponyfill for this which is also mentioned in the olivero color issue #3086514: Investigate use of the changing color themes for Olivero as option 2 as a submodule of cssvars.

I also tested it on a site with domain specific overrides.

Everything works nicely now and it's fun just to dump in all kinds of variables such as size as well which is also a huge benefit compared to core color module!

This sounds very exciting! I'm not keen on throwing the color module out of core, so I'm glad to hear there's a feasible approach to modernizing it, and keeping it relevant. Both Claro and Olivero have had discussions about colour support, and I've heard that some distros and/or sales demos are still keen on it.

I notice the contrib module (cssvars) doesn't have the word "colour" in the name. Does this mean it has ambitions beyond just colour?

> I notice the contrib module (cssvars) doesn't have the word "colour" in the name. Does this mean it has ambitions beyond just colour?

Yes, it leverages css variables aka custom properties, see https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_proper...

Color and size are defined (and tested) as types atm (see https://git.drupalcode.org/project/cssvars/blob/8.x-1.x/cssvars/config/s...), but if I understand it correctly css variables go even beyond that. E.g. see https://drafts.csswg.org/css-variables/#defining-variables

Replace -- is a strong word.
I think it's important to keep in mind color module is designed to alter/shift color's from images. Whereas we're not talking about expanding that into cssvar.. The usefulness of applying color to images still remains for various use cases.

Expanding Color to handle class based elements decoration would be awesome

i've used both methods in commercial and contrib products.

@SKAUGHT isn't that a legacy feature because browsers could not properly render transparent images in de past?
Over the past years I have achieved color shifting images with (semi)transparent images and background colors.

no...Drupal core's Color module takes a transparent grey scale image and applies 'colors' to it, generating a new image. Color not a polyfill for PNG transparency.. thank god IE6 is very dead now.. took so long...

the snapshot above is more similar to Color Field use (but isn't directly..)

What people are proposing now is to basically alter css additions ontop of sheets (i could be mistaken: i'm not sure cssvar edits/replaces specific items in existing sheet, then sets out a new one..)

Let's look at what color is described as: "Allows administrators to change the color scheme of compatible themes."

In that sense cssvars does qualify as a replacement for color because it makes it possible to change colors.

Actually I'm not really aware of colors functionality to change images. If we make that a requirement for a color replacement, cssvars alone will not do the job, true. Looking at all the technical flaws (e.g. for deployments) of color module and the long standing discussion about moving it to contrib, I tend to be in favor of moving color to contrib even if the replacement does not cover all its functionaltities. Looking how little maintanence/modernisation has been done to color module during all the time it has been in core I even do not see a disadvantage for people then using it as a contrib module.

'live preview' has a large scope. in terms of editing content and displaying a view mode in some context is different that previewing color selection across a theme. which color module provides a preview of!

as an issue listed against the cssvar module to provide a 'live preview' it seems like any theme using Color now needs to provide for those elements/components that will finaly be previews for.. that will be needed to make that preview.

FWIW, we've implemented a live preview in Backdrop since 1.11.0 (which means it's been tested for 1.5 years now).

Here's what it looks like when configuring Basis, the default FE theme:

...the preview is clickable, so one can browse a version of their site with the colors they have chosen. It works quite well actually. You can even open the preview in a separate/dedicated browser tab/window (?preview=basis is being appended to the URLs to make this work).

You can test this by spinning a demo sandbox here: https://backdropcms.org/demo (usually takes only 5sec)

I am intrigued and dismayed with the whole process of coloring themes. Many,many people find it tiresome staring at dark text on a white or lite background. Not just the visually impaired. Multiple studies have been done on this subject. Scientifically speaking it is easier to see a small lite object on a dark background than the other way around. The majority of websites fall short of being comfortable on the eyes. If you are trying to communicate an important message or sell a service or product, Ease of access for the viewer is paramount. For people wanting to design top level websites, a simple and direct (uncomplicated) module for color is a must. My coding abilities are far from advanced. But it would seem to me that a sub directory or file that lists only the colors of all objects in a theme with a link to the actual line in the style sheet could be a very efficient way to go about it. In other words a separate style sheet for colors. I apologize for the lengthy message but I believe that color is a fundamentally important aspect of web communication that is too often overlooked.

Agreed on the importance of this feature! Next steps, we need a strategy and design for this to get enough +1 and a plan to make this a reality :)

+1 on the importance of this feature! As a result of the lack of this feature we started a Sub-theme to Claro called "Gin" (https://www.drupal.org/project/gin) which provides us a possibility to change the Accent color for our customers for better customization of the admin UI. It's more a proof-of-concept, but you'll be able to set your custom Accent color.

Test Setting is a simple color picker field:

Test output:

What I would love to see as features for he long run (also keeping the "Next Generation Admin UI" in mind) I think that we should provide similar options to what Slack offers. A preset of a11y save colors to choose from and the possibility to override the defined parts of the theme with your own custom colors (with the note that these might not be save colors from an a11y perspective).

And it could even be further extended to include other settings too (darkmode, high-contrast mode, reduce motion etc.)

Screenshot of the Slack color customization UI:

So something like this would be possible at a later stage:

Re. #20:

And it could even be further extended to include other settings too (darkmode, high-contrast mode, reduce motion etc.)

There are some red herrings here.

1. Reduce-motion has nothing to do with the colour scheme. More importantly, it has nothing to do with site-builders. A theme can have built-in support for this user-preference media feature, but I'm struggling to see any use-case for this being something that changes based on a site builder's choice.
2. In high-contrast mode (a.k.a. forced colours) the colours specified by the website are forcibly overriden by a limited palette chosen by the visitor. The site-builder gets no say in this. There may be a use-case for a few configurable changes (such as replacing a logo image), but not many.
3. Were you thing of the prefers-contrast media feature instead? That's a different feature from high-contrast mode. Here it would make sense for a theme to include a higher and lower contrast version of the accent colours.

The primary obstacle for CSS Custom Properties is our commitment to support IE11. I've worked with the IE11 "ponyfill" polyfill before, and it has some real limitations (as of a year ago at least) including you must declare all custom properties in the :root element. In addition the custom properties are not dynamic, meaning that they can't be modified as the browser adjusts to new media query breakpoints.

I've been meaning to play with a new polyfill, https://github.com/nuxodin/ie11CustomProperties, that supposedly solves these issues, and supposedly fixes these issues within IE11.

I'd love to work with someone on this, if anyone is interested!

Cross linking this new issue within the Olivero issue queue: #3150283: Investigate use of new IE11 polyfill in place of PostCSS custom properties

Unfortunately when I evaluated the polyfill, it pegged the CPU at 100% for many seconds (on the computer running IE11). The polyfill as it stands now is a no go. I opened up an issue for the polyfill at https://github.com/nuxodin/ie11CustomProperties/issues/54. The maintainer seems to be pretty responsive.

Cool lets see if this can be addressed by the maintainer

Currently thinking how to replace the SCSS based color_schema_ui from deGov distribution.

As a frontend dev I think css variables are the road to go.

* Allows easy in-place updates (as we have in color_schema_ui)
* Clean "API" to implement things like Contrastdark mode
* to support ie11 can be polyfilled at long as you're processing root-level custom properties

One part I see just outputting some css somewhere early. And could maintain the data with color Module

:root {
    --color-primary: red;
    --color-secondary: gold;
    --primary-contrast: green;
}

I tried to keep things simple.

Currently missing:

• UI to select colors while on the frontend is on the todo list. We have some JS widget in color_schema_ui which did exactly that.
• Color variable derivates like lighten() darken() opacity()
• ie11 polyfill

Please have a look at https://github.com/digitaldonkey/css_color_variables or maybe soon https://www.drupal.org/project/css_color_variables

Adding the Drupal 10 deprecated modules issue as related.

Oh no!! Some browsers not support css variables
https://caniuse.com/css-variables

just imagine if your site how to shows without colors.

Support for IE 11 and opera mini will be droped in core 10 so all other browsers support it

I think this can be closed now that #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated is decided. The color module is no longer matching with current standards and will be removed from core. However the need for color changing themes is recognised in #3257274: Implement color changing theme settings for Olivero (which will use a CSS variable based approach).

For everbody intersted in thinking along, please tune into #788332: Provide a parser for THEME.colors.yml to help build a core system to expose and extract theme color information. That is the very least a contrib color module will need to universally work with different themes. The fancy UI can then live in contrib.

Yes, the Color module is now in contrib. I am closing this based on #33.