Remove ::selection style from off-canvas dialog reset

Screenshot for issue summary

Should be an easy patch

@Gauravmahlawat - thanks for working on this issue.

1. The change you've made to core/misc/dialog/off-canvas-reset.css is right.
2. The same change needs to be made in the stable and stable9 core themes. Look for files with the same name in those themes.
3. The reason your patch failed to apply is that it has the /web/ step in the paths (in the first line of the patch). Core patches need to use paths relative to the git repo root (so they should begin with diff --git a/core/). It sounds like you're working with a site installed by composer create-project drupal/recommended-project? That's the recommended approach for managing a website, but for core contribution you'll want to start with a separate repo by using git clone. See the guide to Making a patch.

Re. #9:

Is this a case where the CSS rule all: initial would work to reset any style overrides?

Unsure, haven't tried it. However it sounds very risky to me. Remember that initial is supposed to set it back to the initial value specified in the CSS recommendations, which isn't the same as the user-agent stylesheet.

• For color the initial value varies by user-agent (e.g. currentColor), but CSS level 4 aims to standardize on the CanvasText system colour keyword, i.e. normal text. That often computes to black (but will differ if OS features like high-contrast mode, dark mode, or other native widget theme/skins are used).
• For background-color the initial value is transparent.

These are almost certainly NOT what we hope for in a selection style.

What I'm unsure of is whether user-agents would actually treat this as CanvasText-on-transparent, or decide that it needed to use a UA style.

#drupal-off-canvas ::selection, #drupal-off-canvas ::-moz-selection {
    color: initial;
    background-color: initial;
}

So we can rule out the approach suggested in #9.

I also tried using revert and unset which aren't any better. Colours are inherited properties, so both of these result in the selected text looking exactly the same as the unselected text. So the selection is effectively invisible!

Re. #8 - thanks for finding the issues/commits @maxstarkenberg

Though doing some cursory grepping in some versions/varieties of Bootstrap, I'm not finding setting of ::selection color, but I could just be looking in the wrong places.

Thanks! I confirmed this too, by checking out every tagged x.y.0 version of the twbs/bootstrap repo. Grepping for "selection", I found no instances of ::selection or -moz-selection. So the core Bootstrap library has never done this. Maybe the various Bootstrap "themes" set ::selection styles? I wouldn't relish doing a survey of those.

normalize.css and the Meyer reset.css don't use the selection pseudo-element either.

The HTML5 Boilerplate starter DOES style the ::selection though, so perhaps these styles are present in some Drupal themes. Versions 1-3 used a hot/bubblegum pink selection background, and versions 4-8 use a light blue background. The doc comments explain the motivation is to remove a text-shadow from some user-agent styles, but that doesn't explain their use of colour properties.

So the concern in the original issue may be warranted, but we have no way of knowing how widespread the use of custom selection styles is. It certainly isn't "all Bootstrap sites" though.

Meanwhile, we're missing the glaringly obvious fact that this rule in off-canvas.reset.css doesn't actually work in Blink, Webkit, IE, or old-Edge:

/* To standardize off-canvas selection color. */
#drupal-off-canvas ::-moz-selection,
#drupal-off-canvas ::selection {
  color: inherit;
  background-color: rgba(175, 175, 175, 0.5);
}

In fact this has only ever worked in Gecko-based browsers, because when browsers don't recognize one of the selectors (::-moz-selection), the entire rule is ignored.

I confirmed this by shoving ::selection, ::-moz-selection { background-color: orange; } into Bartik. Sure enough, selected text in the off-canvas dialog gets an orange background in Chrome, but a grey background in Firefox.

So, it's never worked in most of our supported browsers (in any stable Drupal core release since it was added in mid-2017), while it leads to a WCAG contrast failure in the only browser where it does work. That gives me some confidence that just removing it outright won't be a disaster.

Back to needs-work, to remove it from stable/stable9 themes.

Updating problem section, to mention that user-agents respect OS-level colour for highlighted text, which is a configurable user-preference on most desktop OS.

Forgot to say earlier, that @Lendude deserves a credit here too. He 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. So that guided the proposed resolution to remove this rule.

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