Repository navigation
[css-pseudo] highlight pseudos and non-applicable properties #7591
Description
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.
Activity
fantasai commentedon Sep 1, 2022
That's a very interesting question! I think I lean towards ignoring declarations of non-applicable properties, so you'd get a computed font-size of 42px and a 42px text-shadow offset. I think this would give the most reasonable and useful results, from an author's perspective.
andruud commentedon Sep 1, 2022
But ignoring would get you the initial value (typically font-size:16px), not 42px?
css-meeting-bot commentedon Sep 15, 2022
The CSS Working Group just discussed
highlight pseudos and non-applicable properties, and agreed to the following:RESOLVED: Properties that don't apply on highlight pseudos are ignoredRESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the elementThe full IRC log of that discussion
<heycam> Topic: highlight pseudos and non-applicable properties<heycam> github: https://github.com//issues/7591
<heycam> fantasai: look at the example in the issue
<heycam> ... it's showing a ::highlight with a text-shadow with an offset expressed as 1em
<heycam> ... there's a parent selection pseudo with a font-size:69px, and the actual element has a font-size:42px
<heycam> ... font-size does not apply to ::highlight, so the actual font is going to be 42px
<heycam> ... the question is, when we're computing the value of 1em, are we using the font-size assigned to the selection even though it doesn't apply, and cannot apply, or do we ignore that font-size and use the value from the originating element?
<dandclark> q+
<heycam> s/::highlight/::selection/
<heycam> fantasai: implementations do various things. Blink uses the initial value, which is 16px
<heycam> ... the question is what do we want to do?
<heycam> ... using the actual font-size would give the most expected results from the author perspective
<heycam> dandclark: I agree with that
<Rossen_> ack dandclark
<emilio> q+
<heycam> ... definitely seems the most intuiitive thing here, i.e. the font-size of the originating element
<heycam> ... anything else seems strange to me
<Rossen_> ack emilio
<heycam> emilio: we have precedent for this
<heycam> ... things like ::placeholder already ignore a bunch of properties, and they do so by ignoring the declarations
<heycam> ... so as if the font-size declaration wasn't there
<heycam> ... I htink that's what's being proposed here, and I think that's reasonable
<heycam> fantasai: proposed resolution is we use the actual, effective font-size (and font-family, etc.) here
<heycam> emilio: can we word it as declarations of not supported properties are ignored instead?
<heycam> fantasai: it inherits from the parent selection
<heycam> emilio: that's trickier then
<heycam> fantasai: we can say both things
<heycam> emilio: I think that's weird
<heycam> ... I'd rather keep it simple and ignore the declarations
<heycam> astearns: if we ignore the declarations, and just do the normal inheritance, even though the value is ignored, don't we get what we want?
<heycam> fantasai: you get the initial font-size
<heycam> emilio: or the root element's font-size
<heycam> ... weird to add another source of inputs here
<heycam> Rossen: if we don't do that what makes most sense?
<heycam> ... on one hand we have the default 16px
<heycam> ... that seems less useful
<heycam> astearns: don't understand why we get the initial font-size
<heycam> ... the pseudo is on an element that has a font-size
<heycam> fantasai: but it doesn't inherit from that element
<heycam> ... ::highlight inherits from the parent element's selection
<heycam> ... we rewired highlight inheritance like this
<heycam> Rossen: the intiial font-size, is that because you simply end up with the root size?
<heycam> fantasai: yes
<Rossen_> ack dbaron
<heycam> dbaron: I was just thinking about the desired behavior here
<heycam> ... if you have a selection with text-shadow that's got a 1em in it, and that selection crosses elements with different font sizes, do you actually expect that the shadow has a different offset or spread as the selection crosses those elements?
<heycam> fantasai: maybe, maybe not
<heycam> ... depends on what you were aiming for with the effect
<heycam> ... I think having it be consistent across them is not unreasonable
<heycam> Rossen: what do we do for outline?
<heycam> fantasai: that doesn't inherit
<heycam> dbaron: one of the other factors here is that a principle about selection styling is that you shouldn't get different results depending on where the selection starts
<JakeA> q+
<heycam> ... so if your selection starts further up ancestor, which has a different font-size, versus a narrow selection scoped to a descendant with a different font size, those descendants shouldn't render differently
<heycam> fantasai: I think both proposals follow that principle
<Rossen_> ack JakeA
<heycam> JakeA: is currentColor an issue here? for the same reason?
<heycam> fantasai: currentColor inherits as its own keyowrd, and resolves on each element
<heycam> ... for highlights it has some special behavior
<heycam> ... I think maybe it's just on the color property? it doesn't look as its parent, it looks at its originating element
<heycam> Rossen: I think following David's principle, that principle is satisfied
<heycam> ... from the user's PoV this is arguably what you want
<heycam> ... to Jake's point, if we model this on the same way color / currentColor works ...
<heycam> fantasai: color inherits from the parent selection, not the originating element
<heycam> ... currentColor on all other properties than color, looks at color
<heycam> ... normally color:currentColor is like inherit, but for highlights it takes the originating element's color
<heycam> ... so if you have a highlight where you're only doing say underlining, it gives you a way to "use the original color"
<heycam> ... rather than parent's color
<heycam> Rossen: so for em resolution
<heycam> ... seems like we could have the same behavior
<JakeA> q+
<fantasai> heycam: If you set font-size:inherit...
<fantasai> heycam: analog is, you're using the currentColor keyword on a property other than color, is the analogy is for having em values in some other property
<fantasai> heycam: if you used em values in the font-size property, that's more of an analog to using currentColor in color property
<Rossen_> ack JakeA
<heycam> JakeA: when you talk about the originating element of the highlight
<heycam> ... what happens in the case where the highlight spans multiple elements?
<heycam> fantasai: multiple pieces of highlight, each has an originating element
<heycam> ... if we consider dbaron's comment, making font relative values always resolve against the initial values seems to be most consistent with the principle
<heycam> Rossen: I'd argue from a user PoV that makes no sense
<heycam> ... [something about highlight sizes]
<heycam> fantasai: the size of the highlight doesn't change
<heycam> dbaron: I tend to be in favor of what Elika just proposed
<miriam> q+
<heycam> ... the alternative seems like it would be hard to implement
<fantasai> proposal was that, since having consistent resolution from 1em is not unreasonable in many cases, and is already implemented in Blink, then we should resolve on that
<heycam> ... and I don't think we've heard any good use cases for the alternative, i.e. do people really have demands for em offsetted text-shadow that varies on elements
<heycam> miriam: would it be closer to author intent to use root ems instead of browser default?
<heycam> emilio: that's the behavior you get when you ignore declarations
<Rossen_> ack miriam
<heycam> fantasai: I think the spec is a bit unclear on that
<heycam> ... so whatever we decide here is how we'll clarify it
<heycam> Rossen: hearing consensus forming around Elika's proposal, with using root ems intead of the initial value of font-size
<heycam> ... any other proposals?
<heycam> dandclark: should this be more general than font-size?
<heycam> ... lots of other properties that don't apply to highlights
<heycam> fantasai: we're applying it to all font properties, taken from the root
<heycam> ... all of the decalrations on pseudos that are defined not to apply are ignored
<heycam> fantasai: proposed resolution: declarations on highlight pseudos defined as not applied are ignored, and font properties are all taken from the root element
<heycam> RESOLVED: Properties that don't apply on highlight pseudos are ignored
<heycam> fantasai: I think we say that for the ::selection on the root element (and therefore inheriting down into other highlights), all of the font settings are taken from the root element
<heycam> RESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the element
HighlightInheritance: fix ‘text-shadow’ with font-relative units
HighlightInheritance: fix ‘text-shadow’ with font-relative units
HighlightInheritance: fix ‘text-shadow’ with font-relative units
HighlightInheritance: fix ‘text-shadow’ with font-relative units
HighlightInheritance: fix ‘text-shadow’ with font-relative units
9 remaining items
andruud commentedon Sep 18, 2023
Are these resolutions saying that font-relative units within the highlight resolve against the originating font-size, but font-size itself (on the highlight) is not affected?
schenney-chromium commentedon Sep 29, 2023
To help developers understand which font is used for resolving metrics, we'll be reporting the font size, line height and other related properties on the highlight's getComputedStyle. Sometime in the next week I'll update the spec draft.
Add discussion of properties from the originating element
[css-pseudo-4] Take certain non-applicable but required properties fr…
[css-pseudo-4] Tighten up text about non-applicable properties taken …
fantasai commentedon Oct 15, 2024
@schenney-chromium I merged your PR, but also added a fix-up commit 3b3a022 ; take a look and 1) make sure it's all correct and 2) try to understand why I made the changes I did for next time, and if any of it doesn't make sense ask me about it ;) and 3) close the issue if you're satisfied!
schenney-chromium commentedon Oct 15, 2024
Thanks for landing and correcting. My understanding of the simplified text is that this is a spec, focused more on "what" should happen and not "why". I'll keep that in mind with future edits.
HighlightInheritance: fix ‘text-shadow’ with font-relative units
Bug 1796747 [wpt PR 36582] - HighlightInheritance: fix ‘text-shadow’ …