RiverLea: issue149, restructure/simplify colours to ease stream-making/customiser

[vingle]

https://lab.civicrm.org/extensions/riverlea/-/issues/149

This big change to RiverLea does several things:

• reduces the number of background colours, changes their names to add more meaning about them.
• auto-generates more colours using color-mix() and hsl(), making it easier for customisers to change one colour value (e.g. --crm-c-success) and have related colours auto-generated (e.g. --crm-c-success-light). This has been done on some background colours, some emphasis colours, and alternating rows in tables / checbox groups.
• moves more of the background colours out of RiverLea core, to make the application of bg shades across a stream more predictable.
• Renames background to bg where it's found.

An example of the impact of changes: previously if you duplicated a stream and changed --crm-c-page-background to the background colour you want, a bunch of other parts of the UI would change to that colour too. The parts would vary depending on which Stream you were on - it was neither consistent or predictable. Now --crm-c-page-bg applies just to the background.

The reason so many changes have been done together is testing 4 streams in light and dark modes is time consuming, so it's easiest done all at once.

I have yet to test this PR - and will do this now the changes are complete.

Changes in more detail

1. Background structural change:

• layer0-bg - table, input, etc backgrounds - normally white.
• page-bg - the backmost element of the design, and not much else (currently crm-c-page-background)
• container-bg - the first layer on top of the background (currently crm-c-background)
• layer1-bg - normally the first layer on top of that (currently crm-c-background2)
• layer2-bg - and typically on top of that - auto-generated (currently crm-c-background3)
• inverse-bg - dark-header - needs to contrast with white text on top
• crm-c-background4 & crm-c-background5 have gone.

3. Swaps lots of colors to color-mix(), allows for fewer variables, more automtated colours. hsl() is used in a few places when luminescence is the main thing being changed.

• crm-c-layer2-bg (crm-c-background3) is auto-generated from crm-c-layer1-bg (crm-c-background2).
• Alternating rows auto-generated from one colour, normally with a 92% / 8% #000 tint, so will support any base row colour.
• Hover-states of table rows are also auto-generated mostly (previously many used background variables).
• emphasis colour (success, warning, danger, info) light backgrounds (e.g. --crm-c-X-light) are now auto-generated.
• emphasis on page-bg colours are now following the base emphasis colour, again making generation simpler.

4. Reduces alternating table row colours to just two - row-bg and row-hover. Auto-generates alternating colours, alternating hover colours, and sort column colours (visible in Extensions manager, no way to do that SearchKit as no classes). NB - this forces the alternating colour to be a fixed tint of the bg colour. If you want alternating red and yellow row colours, this won't help that.

5. Shortening selector lists with :is() when a chance is spotted (not comprehensive, just an ongoing process).

6. Darkens checkbox row colours for darkmode Minetta.

Have tried to keep current UI as close to unchanged as possible. If something has changed it's probably a bug. Notable changes are screengrabbed in the first (now closed) PR - #33626.

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[colemanw]

Ooh, color-mix() is cool.

[vingle]

@colemanw - yeh v cool. I thought I could completely swap hsl() for it but that’s still needed in some places. But the hacky background-gradient I’m using for buttonhover tints can go (just noticed they’re still in RL so this needs another commit).

[colemanw]

@vingle I wonder if CSS can now do what we were previously using javascript for:

civicrm-core/js/Common.js

Lines 1975 to 1983 in 35103b4

	// Used to set appropriate text color for a given background
	CRM.utils.colorContrast = function (hexcolor) {
	hexcolor = hexcolor.replace(/[ #]/g, '');
	var r = parseInt(hexcolor.substr(0, 2), 16),
	g = parseInt(hexcolor.substr(2, 2), 16),
	b = parseInt(hexcolor.substr(4, 2), 16),
	yiq = ((r * 299) + (g * 587) + (b * 114)) / 1000;
	return (yiq >= 128) ? 'black' : 'white';
	};

[vingle]

@colemanw

Unfortunately only by describing each colour as separate rgb variables, then doing some calc (https://css-tricks.com/switch-font-color-for-different-backgrounds-with-css/).

contrast-color is the dream css for this in the pipeline, but so far only Safari have implemented, so it's a few years away.

But maybe that JS could be used in the customiser to auto-select the right text colour variable to sit on top of a button/bg colour and save the user from figuring it out / getting it wrong.

[vingle]

@artfulrobot - in this quite bit refactor of colours and variables names - the relevant bits for Thames - other than changing variable names I've removed a couple of your override bg colours on details and summary here and in your dark.css - as it was rendering illegibly on SearchKit edit screen. But maybe there's somewhere else you have details without crm-accordion-light/dark classes that need this - so flagging.

[colemanw]

@vingle the merge conflict is between 2 changes of yours it seems:

<<<<<<< HEAD
.crm-search-admin-edit-columns details {
  background-color: var(--crm-c-page-background);
  margin: 0;
=======
.crm-search-admin-edit-columns details,
.crm-search .crm-search-admin-relative details {
  background-color: var(--crm-c-layer2-bg);
  border-radius: var(--crm-roundness);
>>>>>>> 087fdd3d39 (RiverLea: Colour change, rebase & auto-gen emphasis colours from one value)
  border: 0;
}

[vingle]

Thanks @colemanw - I think that's just since the recent SearchKit accordion merge, the other 17 errors remain…

[colemanw]

Rebased as #33802