You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.