https://drafts.csswg.org/css-pseudo-4/#highlight-styling
The highlight pseudo-elements can only be styled by a limited set of properties that do not affect layout and can be applied performantly in a highly dynamic environment—and additionally (to ensure interoperability) whose rendering within the required area is not dependent on the exact (UA-determined) bounds of the highlight overlay. The following properties apply to the highlight pseudo-elements:
Given the following example, and ‘font-size’ not being applicable to highlights, with an initial value of 16px:
<style>
main, aside { font-size: 42px; }
main::selection { font-size: 69px; }
*::selection { text-shadow: green 0 1em; }
</style>
<main>Hello, world!</main>
<aside>Goodbye, world!</aside>
What is the computed value of ‘font-size’ in main::selection? In other words, can non-applicable properties participate in the cascade for highlight pseudos? Blink currently says no (it uses a “ValidPropertyFilter” to enforce applicable properties in pseudos), but @andruud says yes (69px) based on css-cascade #applies-to.
What is the computed value of ‘font-size’ in aside::selection? In other words, what happens when the highlight cascade does not yield a value for a non-applicable property? Blink currently says we use the initial value (16px). I feel like the originating element’s value (42px) is the most intuitive, but I am also not sure that would be easy to implement, even more so if the answer to question 1 is “yes”.
How far are the ::selection text shadows offset vertically? Blink says both are 1em times initial (16px), but I feel like in an ideal world it would be 42px or 69px for main::selection, and 42px for aside::selection. Blink’s current behaviour is inconsistent with how shadows would work in a non-highlight-pseudo rule, and a violation of least astonishment.
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