(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).