(was: compat risk for ::selection rules defaulting one highlight color from originating element)
Highlight inheritance marks a pretty big change for the already-widely-shipped ::selection. The current consensus as of #2474 is that the impls should change, and the value of making highlights behave intuitively outweighs the compat risk.
I don’t mean to relitigate this, but I recently found a concrete (albeit in WPT) example of breakage that I didn’t realise was possible. I don’t think this breakage should block highlight inheritance, but I just want to make sure everyone’s aware of it.
Before web-platform-tests/wpt#30813, css/css-pseudo/active-selection-012.html looked roughly like this (demo):
<style>
span { background-color: red; color: fuchsia; }
span::selection { background-color: green; }
</style>
<span>fuchsia on green</span>
The test expects ::selection to use a foreground color of fuchsia, default inheriting from the originating element, because the presence of background-color:green suppresses UA default highlight colors via paired cascade. Highlight inheritance broke the test: the ::selection foreground becomes initial, because applicable properties are never inherited from the originating element.
This means that highlight inheritance will break any content where ::selection relies on one highlight color (background-color or color) set explicitly, and the other implicitly inherited from the originating element. I previously believed we would only break content that somehow relies on descendants being reset to initial highlight styles (and doesn’t use universal rules).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3