Web-Facing Change PSA: Stop modifying author-defined selection colors

[Stephen Chenney]

Contact emails

sche...@chromium.org

Specification

https://www.w3.org/TR/css-pseudo-4/#selectordef-selection

Summary

Chromium currently checks all selection highlight colors against the text color and inverts the highlight color if it matches the text. Hence, author-defined ::selection CSS properties may be modified by the browser despite explicit author intent. For example, a CSS rule "::selection { color: cyan; background: cyan; }" the background is inverted and red color is used. In https://github.com/w3c/csswg-drafts/issues/6150 the CSS working Group resolved to disallow the chromium behavior. We propose to implement this spec change and bring chromium into compatibility with other browsers.

Note this is re-starting a previous intent process from a while back.

Blink component

Blink>CSS

Search tags

selection

TAG review

N/A This is bringing chrome into compat with other browsers' existing behavior.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The current Chromium behavior comes from WebKit (trac.webkit.org/changeset/52548/webkit). WebKit has changed this behavior in the past and is no longer doing this. Firefox has never done this. This will align Chromium with the other browsers. Use counter is around 0.0003% (https://chromestatus.com/metrics/feature/timeline/popularity/3934), this will make selected content impossible to read in some web pages (but that's already happening in Safari and Firefox). Or maybe this is making some webpages work as expected, if they were using selection colors to hide some content.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Probably Positive (https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome) There are 5000 views of the Stack Overflow question linked above, suggesting many developers have been confused by this behavior.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

We'll add a new test specifically verifying this behavior. Apart from that, css/css-pseudo/active-selection-018.html fails due to this issue if you enable the HighlightInheritance runtime flag.

Flag name on chrome://flags

Experimental Web Platform Features

Finch feature name

SelectionRespectsColors

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1217745

Estimated milestones

Shipping on desktop	125
DevTrial on desktop	124

Shipping on Android	125
DevTrial on Android	124

Shipping on WebView

125

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5657973985640448

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.