Investigate use of the changing color themes for Olivero

The one thing I can say about the color module is that it basically does a find and replace of #abc123 with the new color you've chosen, in a CSS file, then it writes that CSS file into public files folder, and adds it at the end of the cascade.

So, to support color module, a "base" CSS file needs to exist that defines all the 'colorable' portions of the theme that serves as overrides to what the default CSS is.

CSS Variables need to be investigated as a better way of implementing this.

It should also allow all themeable colours to be included in a single themeable stylesheet.

We now have a working color successor candidate based on css variables, see #3090894: Replace color module with a CSS-Variables based module to provide configurable theme parameters.

> I'm personally concerned about a flash of unstyled content, though.

We integrated the mentioned ponyfill library and indeed in ie11 on my machine I see the flash. This could be worked around by #3090875: Add a server side css variables replacer (for JS-less IE11).

Also cssvars is domain config compatible.

> I'm personally concerned about a flash of unstyled content, though.

An addition to this: The flicker did improve/disappear once I changed the JS that triggers the ponyfill to this:

(function ($, Drupal, cssVars) {
  'use strict';

  Drupal.behaviors.cssvars_polyfill = {
    attach: function(context, settings) {
      cssVars();
    }
  };

}(jQuery, Drupal, cssVars));

(Effectively removing the curly brackets from within the cssVars function, compare https://git.drupalcode.org/project/cssvars/blob/8.x-1.x/polyfill/run-css... This is possible as long as no ponyfill options are needed)

@anruether: Thanks a lot for your investigations in this! Let's discuss this more in the project queue and upstream.

Few ideas, that I was discussing with @mherchel during Florida Drupalcamp:

Allow modern browsers use regular CSS (with vars), but then add special files (ie. ie11-color.css, ie11-fixes.css, etc) to deal with IE11 specific issues while allowing take advantage of latest and greatest features in modern browsers.

Inspired by the ideas shown here (and seems like a simple implementation):
https://dev.to/ananyaneogi/create-a-dark-light-mode-switch-with-css-vari...

Add additional special vars

:root {
    --primary-color: #302AE6;
    --secondary-color: #536390;
    --font-color: #424242;
    --bg-color: #fff;
    --heading-color: #292922;
}

[data-theme="dark"] {
    --primary-color: #9A97F3;
    --secondary-color: #818cab;
    --font-color: #e1e1ff;
    --bg-color: #161625;
    --heading-color: #818cab;
}    --heading-color: #292922;

That will make it easy to add a toggle button and/or use prefers-color-scheme.

Additional interesting ideas we can use can be found here:
https://web.dev/prefers-color-scheme

Reviewing the #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated I can say that the decision on removing the Color module from core heavily depends on whether the new FE theme is going to use it or not. So I guess if the Olivero actually needs the Color, it will stay in core.

OK, so let's look at some other questions:

• Which elements in Olivero will be re-colourable? I'm guessing that will probably be "all the blue things", and we're offering a choice of accent colours instead of blue. Maybe a choice of footer background. Any other schemes?
• How many colour schemes do we want? If we follow Bartik's lead those might be: blue, purple, red, green, grey. Or we could have different ones to Bartik... burgundy, pink, burnt orange. I am not a designer.

It would be nice to have two options. One for a normal theme, and one for dark that would be activated by media-query!

I think support for the prefers-color-scheme media feature is a separate concern, which color module isn't really suited for (in it's current form). Instead, I think there could be a theme setting: dark, light, or respect the user's preference. I'm thinking of the way macOS treats light/dark and accent colour as separate settings. So the site builder could say "red accent scheme, on light background" or "green accent scheme, and respect the visitor's user preference for light/dark mode". If color module is disabled, blue is the only accent colour, but the light/dark functionality is still there.

Adding related issue #2808151: [policy] Move the Color module to a contributed project when Bartik is deprecated.

I add another related issue. We have to have all the colors as variables if we want to be able to change them easily.

https://www.drupal.org/project/olivero/issues/3151405

1. As @jhodgdon said we have at least ~2 years to go with color module
2. I was thinking about how we can deal with it, to easily switch the colours, so i have implemented actually the same thing we use already ~1 year in my Skilld company, let me explain:

I see no reason to go with postcss-custom-properties plugin anymore, instead we have to use css-vars-ponyfill

Globally idea here is to have css variables in the compiled css. I know it doesn't work in IE, that's why css-vars-ponyfill will help here.

3. I added colours implementation to Olivero, check color/ folder in the root. With proper configuration on this page /admin/appearance/settings/olivero we will have this one:

The list of all colours used within the theme. Note that these colours are not really good to me in terms of its names, it should be changed, but it is not really important for this task. This task is an idea what we can do with colours

4. The next thing is a preview with the ability to change colours on the fly. I have added some elements from header and some little js to change colours if you going to edit it, look how it looks if i'll change some:

By default these colours were blue, but when i have changed it on this page - it was immediately have changed with the little js script, which is defined here color/preview.js. Also you can see that "Olivero" word becomes blue, it's because i have changed white color by #00e. Sooo.. we can easily put all needed elements to this preview to see visually the difference if colours will be changed (can be form elements, buttons, footer, text, etc).

5. One more thing - all colours were moved from css/src/base/variables.css to color/colors.css - this is necessary for color module to move it into standalone file.

6. All @import "../base/variables.css"; from all components were removed, coz we don't need to import variables anymore, see the 2nd point (we have now all variables in generated css).

Everything works fine, even in IE11, look at left corner, i have change blue color by violet:

You can change any color from this page /admin/appearance/settings/olivero and it will be applied automatically everywhere, where this color was used in css. (Thanks again to css-vars-ponyfill)

7. I didnt find how i can put css-vars-ponyfill into the theme, so i have copied its sources to js/css-vars-ponyfill.js. Note that this is temporary fix, just for you guys to test / to understand how it feels

Idea of this patch is to forget about IE11 problems about not supported css variables in generated files - it's working fine with css-vars-ponyfill. I'm insist we can update core with that idea and all core themes.

Css variables everywhere :)

> Note that within IE11, there is a flash of unstyled content.

Maybe the on efrom #13 performs better wrt this.

Yes @mherchel, i saw these 2 issues, what i can say is the following:
1. For wrong calc cases i would say we can just adapt those variables, look at here how it is done right now, just an ex:

 --grid-gap--nav: var(--grid-gap--md);
--grid-col-width--nav: calc((var(--grid-full-width--nav) - (var(--grid-gap-count--nav) * var(--grid-gap--nav))) / var(--grid-col-count--nav));

 left: calc(-1 * ((var(--grid-col-width--nav) + var(--grid-gap--nav))));

So what i'm trying to say is that there are nested calc functions inside of another calc. It is normal behavior looks like for IE11 when he can't recognize it properly. That means we need to fix nested calcs.

2. About short moment before ponyfill gets working - yep, looks not really good, but this is how it's working. Maybe we can hide whole content by default for IE? And to show it right after ponyfill has finished his job. Or actually is it really an issue for us?

Tuning in! We colour Olivero into an organization's primary colour - always. It's do-able with a lot of css overrides (packaged into a subtheme). It would be great to have a configuration option for it. Happy to help test any solutions.

I was eager to try out the patch in #17, but it doesn't seem to apply to 9.1.4. Any tips on which version of core I should use?

Thanks for the update, Mike. Looking forward to seeing and testing the stable version.

Our first goal is to get to stable and make Olivero the default. After that, this will be one of the very top priorities.

@mherchel would you mind to link to a roadmap or issue or META where this progress is documented, if it is somewhere? It would be helpful.

Oh no it's fine here :-) (for color)

The issue to make Olivero stable is at #3177296: [META] Make Olivero stable and the default theme for Drupal.

That's what I was referring to. Thanks! +1 (Didn't found it)

Reference: I'll wanted to put the META as related Parent in here to make the reasons for postponed clearer, but I saw #3064880: Create new default front-end theme has been chosen as Parent to this one. So I just left it as it is to not confuse things. EDIT: Wait, the other one is closed (fixed). Ok then, so let's do it? Feel free to change it if it doesn't fit.

It looks actionable now

Wow - Olivero is amazing. I love it! A huge thank you and karma to everyone involved. It's so impressive!

I've just enabled it in an experimental project and was trying to figure out how to change colours like we could do with good 'ol bartik, and ended up here. So a +1 from me this is an important feature for a default theme, so that site builders can easily tweak colours, without having to become themers or developers.

+1 to this feature as well.

https://github.com/nuxodin/ie11CustomProperties/issues/54 suggests the CPU issue may be fixed in the polyfill in the latest release, has this been tested? If this is acceptable I think this can be worked on in D9 - if this is still no use then this issue will have to be postponed until Drupal 10 as unfortunately we need to support IE11 until then.

This would be an awesome feature, complementing #3214072: Provide an Olivero sub-theme creation tool perfectly, to easily create a unique looking theme with minimal effort.

@ressa: +1

Attached is a patch that makes use of the most recent patch in #3217924: Olivero: Convert all colors (blues and grays) to HSL and normalize hues and saturations. . A new number input has been added to the theme setting to allow users to select the base hue value from which Olivero will derive all theme colors. I originally planned to use a color input for this, but decided against it to prevent confusion when as we'd only be utilizing the hue value. This prevents users from selecting different saturation/lightness values of the same color but ultimately getting the same result in the Olivero theme.

Instead, there's now a number input with a step of 0.1 to allow fine-grained control and tweaking of the hue value. To make it easier for users to see the color they're selecting, the number input also has a #suffix that places a span tag that we're styling with a new library in olivero. On load, the span tag picks up the default value, and as the hue selector input changes, the span updates to always show the background color as the most-saturated, and half-lightness version of that hue hsl([value], 100%, 50%)

Re @mherchel in #38: rather than answering whether Color module should be used or not it would be good what's the vision/idea in terms of what kind of color customization would you want to allow practically? The feature gap between #39 and #17 is huge and #39 is actually more appealing in terms of colors working together but appears having a sub-par UX in terms of needing to specify what may appear random numbers for an audience that does not have color theory experience. Either way both are in my understanding proof of concepts, but it would be better IMHO to agree on a direction of what is to be customizable. THEN we can talk about how IMHO :D

Not sure if this is helpful here, but below are two examples of the kind of color customization that we're currently doing for clients to bring in their primary + secondary colours into Olivero -> menu items, links, buttons, etc.

PS -> also for mobile menu -> that's the primary colour (not olivero/drupal blue):

If we are to only pick one color and use browser-native widgets for it (don't build a parallel color module), then in my humbe opinion doing it custom to Olivero is fine.