[css-pseudo] highlight pseudos and non-applicable properties #7591

delan · 2022-08-11T10:45:36Z

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.

(@fantasai, @frivoal, @mrego)

fantasai · 2022-09-01T18:28:48Z

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 · 2022-09-01T20:34:10Z

But ignoring would get you the initial value (typically font-size:16px), not 42px?

css-meeting-bot · 2022-09-15T16:43:05Z

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 ignored
RESOLVED: for the highlight pseudos on the root element, all of the font settings are taken from the element

The 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

The values of properties not applicable to highlight pseudos generally don’t matter, but font properties can affect ‘text-shadow’ if offsets use font- or glyph-relative units. This patch copies those properties from the originating style when initialising highlight styles, as resolved in csswg-drafts#7591 [1]. [1] w3c/csswg-drafts#7591 Fixed: 1350476 Change-Id: I222d9d58f44adaba39a68180e87efae2fd57d1d8

The values of properties not applicable to highlight pseudos generally don’t matter, but font properties can affect ‘text-shadow’ if offsets use font- or glyph-relative units. This patch copies those properties from the originating style when initialising highlight styles, as resolved in csswg-drafts#7591 [1]. [1] w3c/csswg-drafts#7591 Fixed: 1350476 Change-Id: I222d9d58f44adaba39a68180e87efae2fd57d1d8 Cq-Do-Not-Cancel-Tryjobs: true

The values of properties not applicable to highlight pseudos generally don’t matter, but font properties can affect ‘text-shadow’ if offsets use font- or glyph-relative units. This patch copies those properties from the originating style when initialising highlight styles, as resolved in csswg-drafts#7591 [1]. [1] w3c/csswg-drafts#7591 Fixed: 1350476 Change-Id: I222d9d58f44adaba39a68180e87efae2fd57d1d8 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3818830 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#1062958}

…with font-relative units, a=testonly Automatic update from web-platform-tests HighlightInheritance: fix ‘text-shadow’ with font-relative units The values of properties not applicable to highlight pseudos generally don’t matter, but font properties can affect ‘text-shadow’ if offsets use font- or glyph-relative units. This patch copies those properties from the originating style when initialising highlight styles, as resolved in csswg-drafts#7591 [1]. [1] w3c/csswg-drafts#7591 Fixed: 1350476 Change-Id: I222d9d58f44adaba39a68180e87efae2fd57d1d8 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3818830 Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/main@{#1062958} -- wpt-commits: 7678c853fbfd486c3e5feea0005cac97a3ce7673 wpt-pr: 36582

delan · 2023-06-06T12:12:51Z

Unfortunately I wasn’t able to attend the call, but after reading the resolution and the underlying discussion, I think we’ve only really solved the problem for the root highlights. For highlights elsewhere in the tree, making 1em compute to 1rem means that if the text is any other size, 1em will have no connection with reality.

I wonder if we can make ‘font-size’ and ‘line-height’ inherit from the originating element everywhere in the tree (red) rather than :root only (blue), like we did for ‘forced-color-adjust’ and forced colors mode in #7264. I actually misunderstood the resolution at first and thought that’s what we decided, and ended up implementing it that way in CL:3818830 (though there’s currently a bug in how it interacts with zero-cost inheritance).

<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> 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
<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: 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

All of the approaches mentioned including

taking ‘font-size’ from initial values (16px)
taking ‘font-size’ from the originating element at the root only (42px)
taking ‘font-size’ from the originating element everywhere in the tree

obey the principle that descendants should render the same way when the selection is expanded to include ancestors. That said, how big ‘1em’ is in a shadow depends on where in the tree the shadow was defined, because ‘1em’ is not inherited as ‘1em’, but rather whatever concrete size it computes to. This is true for both originating shadows and highlight shadows, but it doesn’t actually violate the principle.

For example, given a page with div { font-size: 7em; }…

<html style="text-shadow: 1em 1em;">foo<div>bar = foo is 1rem 1rem, bar is 1rem 1rem
- and the same goes for html::selection { text-shadow: 1em 1em; }
<html>foo<div style="text-shadow: 1em 1em;">bar = foo is none, bar is 7rem 7rem
- and the same goes for div::selection { text-shadow: 1em 1em; }
<html>foo<div>bar with * { text-shadow: 1em 1em; } = foo is 1rem 1rem, bar is 7rem 7rem
- and the same goes for *::selection { text-shadow: 1em 1em; }

schenney-chromium · 2023-07-13T18:15:11Z

We would like to re-open this issue at the F2F as the chromium implementation has diverged and the result seems to give more intuitive results.

In the previous discussion there appear to be 3 distinct concerns:

shadows or other decorations changing when highlights are expanded to include other elements
shadows or other decorations changing when descendant highlights inherit the property values
the meaning of 1em and 1lh when declared in rules matching some highlight pseudo

Issues 1 and 2 are already well specified and we seek no change in the behavior. Decorations for any given element remain the same for that element regardless of what else is highlighted (issue no. 1) or when descendants inherit values (issue no. 2). The issue is what to expect when highlights need text metrics on elements throughout the tree.

As currently implemented in chromium an element with any highlight pseudo, including ::selection, will use font dependent metrics from the originating element when resolving lengths (such as 1em). As delan says, this aligns with the current spec for ‘forced-color-adjust’ and forced colors mode (see #7264).

The existing resolution talks about the root element, saying that font metrics should be taken from the root element for highlight rendering, but does not say what would happen at other elements. The implementation in chromium defines behavior for every element in the tree. It avoids unexpected behavior when ::selection would pull metrics from the root while *::selection would pull from the initial value. It also has the property that a text-shadow on an element will not change size/offset if the same text-shadow is applied as a highlight. The latter is an important authoring principle: the text-shadow for a highlight should be predictable based on the standard text shadow for the element.

In summary, we propose that "text-related metrics in highlight pseudos use values from the originating element when not available from the highlight itself".

css-meeting-bot · 2023-07-19T16:32:55Z

The CSS Working Group just discussed [css-pseudo] highlight pseudos and non-applicable properties, and agreed to the following:

RESOLVED: If a unit (or similar value) relies on the value of a property that's not appicable to highlights to resolve itself, it uses the value from the originating element.

The full IRC log of that discussion

<TabAtkins> schenney: this issue arises when properties in highlights, like shadow blur radius, etc
<TabAtkins> schenney: use property value s that have font-dependent metrics
<TabAtkins> schenney: or any ohter type of context-dependent value that can only be resolved from outside the highlight
<TabAtkins> schenney: like, you can't set font-size on a highlight, but if you use 1em in the highlight we need to look that up somehow
<TabAtkins> schenney: Currentl the spec would have us walk the highlight chain for a font-size proeprty, never find one, and use the initial value
<TabAtkins> schenney: So the proposal is that property-depedent metrics you find in a highlight property, you take from the originating element
<TabAtkins> schenney: font size, line height, etc
<delan> q+
<florian> q+
<TabAtkins> schenney: So if you use the same property on the el and the highlight you'd get the same behavior
<Rossen_> ack delan
<TabAtkins> delan: a few extra notes
<TabAtkins> delan: font-size and line-height are, as the issue title says, they're not applicable properties for highlights
<TabAtkins> delan: can't actually change them in highlights, we odn't want highlighting to change the font size
<TabAtkins> delan: so when you highlight *in practice* it takes the font-size and line-height from what it would be when it wasn't selected
<TabAtkins> delan: So we're trying to make the font-relative units consistent with that, matching the acutal used font-size and line-height
<TabAtkins> delan: rather than some arbitrary initial value
<TabAtkins> delan: Also, we had a previous resolution for this a while back
<TabAtkins> delan: but it seemed muddled, there were other issues mixed in
<TabAtkins> delan: But all we're really trying to do is resolve what happens when you use em/etc units
<TabAtkins> delan: not really changing anything else here about how shadows or decorations work in highlights, just what happens with those units
<Rossen_> q?
<Rossen_> ack florian
<TabAtkins> florian: So we're not *really* discussing property inhertiance, just unit resolution
<TabAtkins> fantasai: I support this proposal and think it's the right thing, and the fact that it's implemented is great
<Rossen_> q?
<florian> +1
<Rossen_> ack florian
<Rossen_> ack fantasai
<TabAtkins> emilio: can't we just... could we fix the previous issue the same way
<delan> q+
<schenney> q+
<fantasai> TabAtkins: That was the 'don't inherit custom props at all, just from originating element'. That runs into you expect custom props to inherit
<fantasai> TabAtkins: [missed]
<delan> q-
<fantasai> TabAtkins: it ends up being a lot weirder in a lot of cases
<fantasai> TabAtkins: We talked about that solution earlier, i.e. not inheriting custom props at all and inheriting from originating element
<schenney> q-
<fantasai> TabAtkins: that ends up being more confusing, because you can't set custom props on highight a tall, you have to rely on light DOM to inherit
<fantasai> TabAtkins: was confusing that you could set a var() but not set it in the same place
<Rossen_> q?
<fantasai> TabAtkins: Because resolution is off a completely different element
<schenney> q+
<fantasai> TabAtkins: basically it's confusing
<TabAtkins> `::highlight { --foo: 1; --bar: var(--foo); }` would *not* do what you think
<Rossen_> ack schenney
<TabAtkins> schenney: Yeah I think the previous behavior would be the bad author behavior, using differnet metric values than what you'd see if you used that property on the originating element
<Rossen_> q?
<TabAtkins> Rossen_: so do we still have a proposed resolution?
<delan> q+
<TabAtkins> schenney: I propose that font and other metrics that used in highlights, where that value isn't available from a highlight-applicable property, use the originatig element to resolve that unit
<dbaron> dbaron: Just to clarify: that's about whether the property in question is *valid* for highlights, not whether it's used.
<dbaron> schenney: yes
<TabAtkins> delan: I wonder if this could be phrased more simply as "in a highlight pseudo, the values of font-relative metrics come from the originating element"
<TabAtkins> schenney: I'm concerned that any other cases where this problem arises need a general resolution
<TabAtkins> delan: fair
<Rossen_> q?
<Rossen_> ack delan
<delan> q+
<TabAtkins> dbaron: i think there's a very slight risk in the opposite direction, where a unit depends on a combo of proeprties where some are valid in highlights, and there you probably want it from the originating element still and not try to mix things
<delan> q-
<TabAtkins> dbaron: maybe there's no example of that right now
<TabAtkins> Rossen_: so returning to the resolution, any objections?
<TabAtkins> RESOLVED: If a unit (or similar value) relies on the value of a property that's not appicable to highlights to resolve itself, it uses the value from the originating element.

schenney-chromium · 2023-07-25T20:44:31Z

Note the resolution did not address the very first question, which is whether to apply the css-cascade #applies-to rules. In chromium, assuming it's feasible, we will say "yes", you can set a font-size property which will affect font-size-dependent lengths. If there's no font size we use the originating element font. Also, container queries can influence lengths, and there we will also attempt to use the originating element to resolve the container query.

A question came up about shadow trees. Looking at the implementation, it seems chromium uses the shadow root as the originating element for the purpose of forced-color-mode etc. We continue to do that and revisit the implementation if it seems to cause problems.

andruud · 2023-09-18T12:55:54Z

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 · 2023-09-29T17:12:45Z

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.

Spec issue: w3c#7591 Per resolution, properties not allowed on highlights but otherwise required to resolve units or modify colors are instead taken from the originating element.

hober added the css-pseudo-5 label Aug 11, 2022

fantasai added the Agenda+ label Sep 1, 2022

astearns added Agenda+ TPAC and removed Agenda+ labels Sep 8, 2022

astearns added this to 5:00-6:00 in TPAC Thursday 2022 Sep 11, 2022

astearns moved this from 5:00-6:00 to 9:00-10:00 in TPAC Thursday 2022 Sep 13, 2022

mozilla-apprentice mentioned this issue Sep 15, 2022

[css-pseudo] highlight pseudos and non-applicable properties mozilla/wg-decisions#889

Open

astearns removed the Agenda+ TPAC label Sep 15, 2022

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Sep 15, 2022

chromium-wpt-export-bot mentioned this issue Oct 21, 2022

HighlightInheritance: fix ‘text-shadow’ with font-relative units web-platform-tests/wpt#36582

Merged

delan mentioned this issue Feb 8, 2023

[css-pseudo] Custom properties on :root #6641

Open

schenney-chromium added the Agenda+ F2F label Jul 13, 2023

atanassov added this to Unslotted in Cupertino F2F Agenda Jul 13, 2023

astearns moved this from Unslotted to Wednesday in Cupertino F2F Agenda Jul 16, 2023

css-meeting-bot removed the Agenda+ F2F label Jul 19, 2023

mozilla-apprentice mentioned this issue Jul 19, 2023

[css-pseudo] highlight pseudos and non-applicable properties mozilla/wg-decisions#1180

Open

chromium-helper mentioned this issue Jul 19, 2023

[css-pseudo] highlight pseudos and non-applicable properties chromium-helper/csswg-resolutions#173

Closed

fantasai added css-pseudo-4 Current Work and removed css-pseudo-5 labels Jul 27, 2023

schenney-chromium mentioned this issue Aug 31, 2023

[css-pseudo-4] Support for highlight pseudos declarations inside @container media queries #9280

Closed

schenney-chromium self-assigned this Sep 29, 2023

schenney-chromium mentioned this issue Sep 30, 2023

[css-pseudo-4] Add discussion of properties from the originating element #9428

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-pseudo] highlight pseudos and non-applicable properties #7591

[css-pseudo] highlight pseudos and non-applicable properties #7591

[css-pseudo] highlight pseudos and non-applicable properties #7591

[css-pseudo] highlight pseudos and non-applicable properties #7591

Comments