When selecting the following (demo):

<style>
.example1::selection { text-decoration: blue underline; }
.example1 sup::selection { text-decoration: green overline; }
.example2::selection { text-decoration: #66339980 underline; }
.example3::selection { text-decoration: underline; }
</style>
<span class="example1">Hello, <sup>world</sup>!</span>
<span class="example2">Goodbye, <span>space</span>!</span>
<span class="example3">On my way, <sup>core</sup>!</span>

1. Should “world” have (a) green overline and blue underline, or (b) green overline only? The underlying question is… do highlights support something like decoration propagation?
2. Should “space” be (a) underlined twice yielding a darker line, (b) underlined once yielding the same line colour, or (c) not underlined at all? The underlying question is… if highlights do propagate decorations, wouldn’t that interact poorly with highlight inheritance treating all properties as inherited?
3. Should “core” appear to have underlines on (a) superscript baseline and normal baseline, (b) superscript baseline only, or (c) normal baseline only? The underlying question is… if highlights don’t propagate decorations, with text instead relying on inheritance to still be decorated in descendants, wouldn’t that be inconsistent with how decorations should generally render in descendants?

We want to be careful not to inadvertently favour the incorrect decoration impl in Blink^ and WebKit, where descendants paint propagated decorations as if they were specified directly — equivalent to 3(b) in non-highlight content.

(cc @frivoal, @fantasai, @mrego, @MatsPalmgren)

^ fixed for underlines in Chromium 105