Remove ::selection style from Olivero

The only other place where Drupal core styles selected text is in the off-canvas dialog. I've filed a separate issue for that - #3196430: Remove ::selection style from off-canvas dialog reset.

Hi @Gauravmahlawat - thanks for looking at this issue.

1. The reason your patch doesn't apply is that it uses paths relative to the Olivero theme directory. Core patches need to use paths relative to the root of the core git repository (see the first line of the patch on this comment).
2. Your patch also only changes the .pcss.css file. It also needs to update the processed .css file. See Drupal core using PostCSS for development for the necessary steps to do that.

However, I'd already done the necessary work in the patch on comment #2.

Re-posting the patch from #2 as the latest one for review (no interdiff needed).

It affects accessibility in several ways, but not all covered by WCAG success criteria.

The main reason to avoid setting a ::selection colour is that it clobbers user preferences. The MDN article on ::selection has a section on accessibility concerns, and emphasizes: "Don't override selected text styles for purely aesthetic reasons — users can customize them to suit their needs". Here's how that works in practice. Most desktop operating systems offer a way for users to choose their own highlight colour for selected text:

• macOS lets users choose ANY colour for highlighted text (separate from the accent colour used by other widgets). It's really easy to do this at "Apple menu > System Preferences > General > Highlight Colour > Other". Safari, Firefox, Chrome, and Opera all respect the user-specified highlight colour.
• Windows 7 provides a GUI for users to fine-tune many colours, including the foreground and background colours for highlighted text. Browsers respect this.
• Changes to the theme features in Windows 10 have removed the ability for users to select a highlight colour. (I've heard that users are very upset by this!) However, it's still possible to change the highlighted text colours using a third-party Windows 10 theme. I've followed that tutorial, and confirmed that Firefox and Seamonkey respect such highlight colours, but Chromium-based browsers do not. (I haven't checked IE11 or Edge 18.)
• On Gnome desktops, the highlight colour specified in GTK3 themes is respected by Firefox. Chromium-based browsers also respect it, but you first have to choose "use GTK theme" in the browser settings GUI.
• KDE plasma desktop allows fine control of many colours. IIRC the Falkon browser (based on QtWebEngine) respects the KDE Plasma highlight colour. Firefox and Chromium browsers don't respect this though; they still use whatever the GTK3 theme says. KDE Plasma does let users choose the GTK3 theme though.
• Mobile browsers don't offer much choice here. iOS doesn't let users choose UI colours at all AFAIK. Android has various theming options, which vary depending on vendor-customized Android distros. I have no idea whether users have any level of control over highlighted text colours.

This is a big deal for users with dyslexia and/or attention impairments. Lots of people use the text highlight as a reading aid, and the ability to customize the colour is a very powerful tool. When an author stylesheet overrides the colours for ::selection, the browsers no longer respect the OS-level highlight colour.

It also clobbers a cool feature of Firefox on Windows and Linux. The browser respects the OS highlight colour, but will dynamically invert it based on the background colour of the web content, to make it more likely that the highlight will hagve good contrast. So if your highlight colour is white-on-purple, it will be inverted to purple-on-white when the page background is dark. But when an author stylesheet overrides the ::selection colours, Firefox no longer applies this inversion feature.

The selected text colour is in scope for WCAG SC 1.4.11 Non-text Contrast. Note that when this is determined by the user-agent, and not modified by the author, it is exempt from that success criterion.

But if we do override the selection colours, then they must have 3:1 contrast against the surrounding un-selected text. This is where the trouble starts, because Olivero is a general-purpose theme for a customizable CMS. We can't know what editor features are enabled, or background colours will be used in the content.

The CKEditor Colour Button module has ~18K installs. It lets editors set the foreground and background colours of text to anything, but doesn't offer any control over the ::selection colours. The blue currently specified in Olivero's stylesheet won't provide sufficient contrast against darker backgrounds, especially blues, greens, and purples.

A more cautious site builder might provide colour choices by using a CKEditor stylesheet and limited classes. This way they could provide ::selection colours for all of their classes. However, that's extra work they didn't have to do with Bartik.

@Lendude deserves a credit here too. They helped out with some macOS browser testing, when I asked in the Slack #contribute channel. My mac is broken so I needed someome to check whether browsers respect the user-specified highlight colour from macOS System Preferences. They confirmed that Firefox, Safari, Opera, and Chrome, all respect the macOS highlight colour choice unless the author stylesheet has overridden the colours of ::selection. If you are logged in to Slack, you can see a record of the contribution in this thread - https://drupal.slack.com/archives/C1BMUQ9U6/p1612515039234300