[css-pseudo] Custom properties on :root

[andruud]

It's a common pattern to define all the primitives in your style guide as "global" (/ attempted global) custom properties on :root, e.g.

:root {
  --pale-blue: <etc>;
  --light-blue: <etc>;
  /* ... hundreds ... */
}

If I understand the highlight inheritance model correctly, such global custom properties would not be available on ::selection (etc), unless you modify the custom-property-defining rule to something like :root, :root::selection {}. In principle what the author would be doing is creating two separate mega-blobs of custom properties. This may or may not be easy to optimize depending on how the usage patterns will actually end up.

Authors can use @property w/ initial value to address it. Is that enough, or we do something else about this?

@delan @tabatkins

[delan]

(summary for meeting)

Same context as the previous issue (#6774). Frontend frameworks often define a whole bunch of custom properties for things like colour palettes, on the root originating element, which used to be available to highlights “for free”. But now they won’t be, and authors will need to define those properties on both the originating element and each highlight pseudo.

[andruud]

Author-defined env() could be something to consider for this.

[tabatkins]

We've discussed using variable values in other contexts that don't inherit from root as well (like in @font-palette, for example).

Having an author-defined env() might work, but would require an author to duplicate values across properties and env(), or else decide for each whether they want to express it as a var or an env().

The idea that's been presented a few times is to special-case properties defined on the root, and make them available more globally, so any context that's not an element with :root as an ancestor can use var() to obtain the root values of the custom property. Would this be reasonable impl-wise?

[andruud]

Having an author-defined env() might work, but would require an author to duplicate values across properties and env(), or else decide for each whether they want to express it as a var or an env().

Yeah, I see how that would be annoying.

OK, then maybe we can specify that var() in non-element contexts use the initial value of custom properties, and then provide a new way of specifying those initial values (if @property is too verbose).

Would [root special case] be reasonable impl-wise?

If we're going to generalize that, I suspect that creates way more complexity than it's worth. We'd be smuggling in the full weight of "computed-value-time", and we'd be unable to interpret any at-rules sooner than that, which is probably not a good thing. For example, the custom properties on :root may be animated, or they may depend on the computed font metrics of the selected font (e.g. with --x:10ch + @property with syntax:"<length>". Fun times if var(--x) is then used in @font-face somehow).

[tabatkins]

Ah yeah that's true, we don't want animation and whatnot to come in. Initial value seems fine to me, and we can just lean on @property unless/until we decide it's too annoying.

[Crissov]

In a later comment in #6099, I suggested something that perhaps could solve this use case, although I did not consider it at the time:

@prefix ns {
  /* global final namespaced custom properties */
  --global: val;
}

:root {
  --miss: var(--global); /* no value */
  --tree: var(-ns-global); /* value: val */
}

::selection {
  --fail: var(--tree); /* no value */
  --miss: var(--global); /* no value */
  --okay: var(-ns-global); /* value: val */
}

[css-meeting-bot]

The CSS Working Group just discussed custom properties on :root.

The full IRC log of that discussion

<emilio> topic: custom properties on :root
<emilio> github: https://github.com//issues/6641
<emilio> delan: there's a lot of content out there where a bunch of custom properties are specified on the :root
<emilio> ... historically that's been fine for highlight pseudos because they inherited from the element
<emilio> ... as spec'd now each highlight pseudo has a separate inheritance tree so it'll break that pattern
<emilio> ... so there's a compat issue in that but I don't think that's a huge issue because we've determined that some breakage is acceptable for these highlight pseudo
<emilio> ... but there's two complications for this, one is that authors at least they'd have to switch their stylesheets to `:root, :root::selection, ...` etc
<TabAtkins> :root, :root::selection, :root::highlight, ... { /* set up all the custom props here */ }
<emilio> ... it's also a bit of a perf issue because we might end up with a bunch of property blobs
<emilio> ... there's another option which is using `@property` with an initial value
<emilio> ... it's a lot more verbose and it should work
<TabAtkins> q+
<emilio> ... I guess question is "is that good enough"? Or can we simplify it somehow for authors?
<Rossen_> ack fantasai
<emilio> fantasai: Wondering about two things we could possibly do. One of them is making highlights inherit from the root by default
<emilio> ... which might be a reasonable thing to do?
<emilio> ... or specifying that variables are special and they inherit from the originating element
<fantasai> probably can't inherit from :root for all properties, but for variables might be OK
<emilio> delan: I think the first idea seems cleaner
<emilio> ... I worry if there are any unintended side-effects
<emilio> q+
<emilio> fantasai: I think the idea is "if you're on the root selection" the variable properties would inherit from the root to `:root::selection`
<emilio> ... I wonder if we want to make this work for every element
<Rossen_> ack TabAtkins
<fantasai> TabAtkins: inheriting from originating element appeals, but assuming we want to inherit from a single place could address a larger concern
<emilio> TabAtkins: Inherit from originating element is appealing but if that doesn't happen this could be an opportunity to address a larger concern
<fantasai> TabAtkins: ....
<fantasai> TabAtkins: Argument for root, animations can play into that don't want to play into other places in the tree
<fantasai> scribenick: fantasai
<fantasai> TabAtkins: Few other suggestions, but if we are going to inherit all the highlights from a single place should do in a way that addresses larger concern
<fantasai> TabAtkins: either use initial value from register Properties
<fantasai> TabAtkins: or .... doesn't have animations apply to it
<fantasai> emilio: Want to point out that ::backdrop has the same issue, ::backdrop doesn't inherit from :root
<TabAtkins> s/..../a more ergonomic way to set initial values that/
<fantasai> emilio: it hasn't come up often, but it hsa come up sometimes
<fantasai> emilio: I would rather avoid inheriting from multiple places, because that's messy
<fantasai> emilio: very special-casy
<TabAtkins> like `@root { /* only custom props here */ }`
<fantasai> emilio: we do something like that for ::first-line, and it's a massive pain. Don't wish that to anyone
<fantasai> Rossen_: where do we go from here?
<fantasai> delan: Agree with emilio in general
<fantasai> delan: I think especially highlight inheritane, but a lot about highlight pseudos, is full of special cases
<fantasai> delan: would prefer to avoid adding more
<fantasai> delan: so maybe it's fine?
<Rossen_> q?
<Rossen_> ack emilio
<emilio> ack emilio
<fantasai> delan: Tab does have an interesting point though, that there's a general problem to be solved. Not sure
<fantasai> Rossen_: I'm a bit lost on where we're going from here. What would you like to see, delan?
<fantasai> delan: Leaving aside the more general issue of how we can use variables in non-element contexts
<fantasai> delan: for the core issue, I think consensus was that the best workaround so far is using custom property registrations with initial values
<emilio> having an `@root` or `@document {}` rule that applies to the whole document makes sense to me fwiw
<fantasai> delan: I guess the question I'm unsure about is do we think that is too annoying and unergonamic? No one had an opinion on that in the thread
<fantasai> delan: do we think that's already too annoying?
<fantasai> Rossen_: for developers?
<fantasai> delan: yeah
<argyle> q+
<emilio> q+
<fantasai> TabAtkins: Lea expresses that she find that's too unergonomic to be worthwhile and would prefer something else here
<Rossen_> ack argyle
<fantasai> argyle: I have lots of experience with custom properties, and it's very tedious to ...
<fantasai> argyle: I have a library called openprops with 350 properties
<TabAtkins> Also I'm not 100% sure off the top of my head how @Property interacts with being nested in @media and @supports.
<fantasai> argyle: I'm not going to hand-author 300 @Property rules so that they can drop into highlight pseudos
<fantasai> argyle: so some kind of higher level place to find these would be great
<fantasai> argyle: would be annoying to convert all my simple props and waiting for browsers to even support that
<Rossen_> ack emilio
<TabAtkins> (to be fair, both of these require waiting for support. but this is simpler than @Property, yeah)
<fantasai> emilio: Mentioned on IRC, but having @document or @root or whatever to apply properties to the initial style makes a lot of sense
<Rossen_> ack fantasai
<emilio> fantasai: one advantage of inheriting from their originating element is that if you need to set variables deeper in the tree you can do that
<emilio> ... and then they'd behave as you expect, you might need to change your ::selection rules a bit
<fantasai> emilio: That was the thing I was thinking about. From an author's perspective, what you want is inheriting from originating element
<TabAtkins> I think we'd define @document in cascade?
<fantasai> emilio: Higher-level thing works for some cases, but might also be more confusing
<fantasai> Tab, but it wouldn't inherit that's the problem
<fantasai> Rossen_: Sounds like we need more discussion, suggest we take it back to the issue
<fantasai> Rossen_: maybe you all can start formalizing the various ideas, would be great
<argyle> 👍🏻
<fantasai> Rossen_: and maybe next time we can be closer to a resolution
<fantasai> delan: sounds good

[argyleink]

@document and @global and @root are the 3 front runners right? enabling an API like this?

@document {
  --indigo-0-hsl: 223 100% 96%;
  --indigo-1-hsl: 225 100% 93%;
  --indigo-2-hsl: 228 100% 86%;
  --indigo-3-hsl: 228 100% 78%;
  --indigo-4-hsl: 228 96% 72%;
  --indigo-5-hsl: 228 94% 67%;
  --indigo-6-hsl: 228 89% 63%;
  --indigo-7-hsl: 228 81% 59%;
  --indigo-8-hsl: 228 69% 55%;
  --indigo-9-hsl: 230 57% 50%;
}

::selection {
  background-color: hsl(var(--indigo-5-hsl) / 25%);
}

channel values from Open Props

[Crissov]

Just for the record, the latest variant of my (shot-down) proposal for prefixes in constant custom properties (#6099) included the @prefix block with rules directly inside of it instead of rulesets with selectors like :root.

@prefix "foo" url("https://example.org/framework.css");

@prefix "foo" {
  --bar: baz; /* available as `-foo-bar` everywhere */
}

@prefix {
  --bar: baz; /* available as `--bar` everywhere */
}

@prefix could become @define, @var, @global, @custom or whatever.

[romainmenke]

@document and @global and @root are the 3 front runners right? enabling an API like this?

Is it correct that you could use this as a replacement for the pattern where a lot of these values are declared in :root now?

If so, I think this is also more inline with the intent behind the author pattern.
I don't think anyone wants to use the whole list of properties on the :root element itself.

As I understand the feature now it also seems possible to downgrade this with tooling, which is always nice.

[LeaVerou]

Just pasting my comments here from the other thread since the issue is discussed here now:

This keeps coming up. We don't want authors to be duplicating colors in these rules, but also we don't want a dependency on the root element's computed style. What if we define a new rule (::document?) where authors can define values for custom properties that are above the root node, i.e. akin to applying to the actual document node. Then media queries and other at rules can use var() references, and they'd resolve relative to that, and because it's not an element, nothing depends on any element's computed style.

@tabatkins

@LeaVerou do you have an objection to the suggestion Anders made, to rely on the initial value of custom props, as defined by @property? Note that you can nest @Property in MQs and other conditionals if needed, to supply the "right" initial value.

I think that's a clumsy solution, as it requires a new @property rule for every single property. Authors tend to define A LOT of properties in their root rules (eg). Even when @property is widely supported, I don't see authors using it for every single custom property they define. Certainly better than nothing though!

[LeaVerou]

Do note that another problem with the "just use initial values from @property" proposal is that these initial values cannot depend on other custom properties, whereas it's common today to do things like:

--color-red-h: 0;
--color-red-s: 90%;
--color-red-l: 50%;
--color-red: hsl(var(--color-red-h) var(--color-red-s) var(--color-red-l));
--color-accent: var(--color-red);

h2 { color: var(--color-accent); /* any color that happens to be the accent color */
.error { border: 1px solid var(--color-red); /* color that needs a specific hue */ }

With an @document (or whatever) rule, would properties inherit down to root etc or would they need to be re-specified on :root?

[faceless2]

The idea that's been presented a few times is to special-case properties defined on the root, and make them available more globally, so any context that's not an element with :root as an ancestor can use var() to obtain the root values of the custom property. Would this be reasonable impl-wise?

It may be more of a hurdle for implementers, but this is really looking like the least clumsy option to me - there's no new syntax for authors to learn, and it's also consistent with @page which is specified as inheriting from :root. So this syntax is already valid:

@page {
    color: --mycolor;
}

It seems weird to me that you can do this in @page, but then have to have a special syntax to do the same in @font-palette or ::selection.

I realise that animating these properties causes problems, but can't we just limit these special cases to be the value when the rule is first specified?

[fantasai]

Going back to the original issue, another possibility is to have var() look up custom properties on the originating element.

[fantasai]

@tabatkins and I discussed this and we think the simplest and best option here would be to define that the highlight pseudos originating on the root element inherit from the root element; and the rest of the highlight pseudo tree inherits from there. That would solve the original request that highlight pseudos be able to take custom property values from the root.

Agenda+ to discuss.

[Loirooriol]

Does this mean that :root { color: black } will prevent the paired default highlight colors?

[tabatkins]

An important part of the discussion I had with @fantasai is that i think --foo: blue; color: var(--foo); absolutely needs to work, and having highlight pseudos change where var() looks up its custom props will break that. As long as that condition is satisfied, I don't have a strong opinion on what else we do, tho I do lean somewhat towards keeping the normal property inheritance and custom property inheritance the same, for simplicity of the model.

So if we do that, the problem is still just the original one - having to specify all the root custom props twice, once for the elements and once for the highlights. The root highlight inheriting from the root element happens to satisfy that.

[schenney-chromium]

Summary for the F2F discussion. The problem is how to evaluate custom property values in highlight pseudos, when the common web practice is to define custom properties on the root element. Options discussed in the past include adding new ways to define document-wide custom properties (@document), but proposals have narrowed to the following options.

• Inherit custom properties from the originating element — there is precedent for pulling property values from the originating element e.g. [css-pseudo] Highlight pseudos and forced-color-adjust #7264 (implemented with some memory usage penalty iiuc) - but they are addressing "where do I get values I can't define on highlights at all" so there is no chance that such values would appear in the highlight inheritance chain. However, custom properties might be defined in the highlight chain, in which case we should use them, and only if not would they come from the originating element. This is challenging from an authoring and implementation perspective.
• Have the root highlights inherit all properties from :root. This is simple but significantly increases the chance of paired defaults getting out of sync when the author sets one color on the root while the other is inherited from the UA style sheet. i.e. selection color and background may cease to have enough contrast.
• root highlights inherit custom properties from :root. The downside is that custom properties defined elsewhere in the tree will not influence highlights, but breakage here is hypothetical and, should authors desire it, the custom property may still be defined on the highlight pseudo inheritance chain.

Maybe in the future we could revisit @document etc. if it would solve multiple use cases.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Custom properties on :root, and agreed to the following:

• RESOLVED: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element

The full IRC log of that discussion

<TabAtkins> chenney: problem with highlight pseudos with custom properties
<TabAtkins> chenney: right now you have to double your custom props on the root
<TabAtkins> chenney: i summarized the options on the isse
<astearns> s/chenney/schenny/
<dbaron> s/schenny/schenney/
<TabAtkins> schenney: from our perspective (chromium/igalia) our preferred option is that custom props come thru the highlight inheritance chain, then if you get to the root and still dont have a vaue for the custom prop, look at the root element
<TabAtkins> schenney: we feel that has advantage of all th eproposals
<fantasai> summary of the options -> https://github.com//issues/6641#issuecomment-1404031937
<TabAtkins> schenney: simple inheritance chain, don't do two lookups
<TabAtkins> schenney: it addresses the problem that most people put custom props on the root, so we don't have to change our advice
<Rossen_> q?
<TabAtkins> schenney: only problem is that if custom props are further down the tree we won't discover them
<TabAtkins> schenney: But an author always has the ability to put them in the highlight inheritance chain manually
<emilio> q+
<TabAtkins> schenney: So proposal is to use the selection inheritance chain, and put the root element at the top
<TabAtkins> schenney: that's the last proposal in my summary
<Rossen_> ack eli
<bramus> The summary being https://github.com//issues/6641#issuecomment-1641196754
<Rossen_> ack fantasai
<TabAtkins> fantasai: So that means highlight pseudos are able to be assigned custom props?
<TabAtkins> schenney: yes, they can use existing from the root, or you can define them in the highlight itself
<TabAtkins> fantasai: okay, just need to make that clea rin the spec
<Rossen_> ack emilio
<fantasai> summary of latest proposal -> https://github.com//issues/6641#issuecomment-1641196754
<TabAtkins> emilio: Is there beahvior difference between this and saying custom highlights always inherit custom props from the root?
<TabAtkins> schenney: I think that is the proposal
<TabAtkins> schenney: We're only saying to inherit custom props from the root not all
<TabAtkins> emilio: Okay as an aside i think the highlight inheritance is funky
<TabAtkins> emilio: but generally i think it's weird that custom props work in some places but not others
<delan> q+
<TabAtkins> emilio: you can't see a custom prop defined on non-root elements
<TabAtkins> TabAtkins: unless you spam them in
<schenney> q+
<TabAtkins> emilio: it makes me sad that this is more complicated and doesn't solve ::backdrop either
<TabAtkins> TabAtkins: ::backdrop is pretty different
<TabAtkins> iank_: the current behavior in the spec is breaking sites, fwiw
<TabAtkins> fremy: What is that bheavior?
<TabAtkins> emilio: a highlight pseudo inherits from your parents highlight pseudo, etc. then the root's highlight doesnt inherit from the root, so you have to specify your custom props on both root and highliht root
<TabAtkins> emilio: Current non-spec behavior is that selection pseudos just inherit from the originating element, no inheritance from the highlight tree at all
<TabAtkins> delan: clarification - the proposal is not that highlight styles inherit from the root, but rather that they continue to inherit from parent highlight styles, but at the top the root highlight inherits from the root element
<emilio> q+
<Rossen_> ack delan
<fantasai> delan: So we're only changing what happens at the top
<fremy> q?
<TabAtkins> florian: for custom props only
<TabAtkins> delan: Right. there was an earlier proposal where we considered doing it for all, and it's simpler, but it breaks paired defautls which are a really important compat behavior
<emilio> q-
<Rossen_> ack schenney
<TabAtkins> fantasai: 1) if we want internally to implement as inherit everything from root to root highlight, you can do that and set "all:initial"
<schenney> q+ now I recall
<TabAtkins> fantasai: you'll have to pull out writing-mode/direction as well. but internally you can just inherit everything and reset a bunch
<schenney> q+
<Rossen_> ack fantasai
<TabAtkins> fantasai: for ::backdrop I think it's completely unrelated, there's no weird cascading/inheritance behavior
<TabAtkins> fantasai: we should discuss ::backdrop but separately. i dont understand why we didn't give it inheritance to begin with
<TabAtkins> fantasai: I feel like this is a good proposal.
<fremy> q+
<oriol> q+
<TabAtkins> fantasai: if you're using custom props in your highlight styling you'll have to set that on the highlight itself, but at that point you're already selecting that highlight so it's not bad
<emilio> q+
<Rossen_> ack schenney
<TabAtkins> schenney: I still think that taking a resolution to consider the broader solution of different place to define custom props (the @document idea from earlier) I think is still important, it would solve other cases
<TabAtkins> schenney: But I think our current proposal for now will fix the breakage we currently see
<Rossen_> ack fremy
<TabAtkins> fremy: I think I agree with that, we should fix the local problem
<TabAtkins> fremy: One comment, to me it makes sense to inherit properties from the originating element
<TabAtkins> fremy: but you say it would b echallenging from impl perspective
<TabAtkins> fremy: why?
<delan> q+
<TabAtkins> schenney: It's *doable* but it requires two sets of inheritance passes to amke it work as authors expect
<TabAtkins> schenney: you'd have to look down the highlight inheritance chain, and if you didn't find a custom variable you'd have to go back to the originating element and walk its inheritance chain
<TabAtkins> schenney: weird behavior from an author's perspective too, it grates me as an author
<Rossen_> q?
<TabAtkins> fremy: It is still confusing to me that you can't make a property called --selection-color and change it further down and ahve it work, you have to send it to the highlight itself
<TabAtkins> fremy: But it's not for me to say what's hard to implement
<TabAtkins> fremy: I do think the root will solve 95% of the problems
<TabAtkins> (I strongly disagree, I think two inheritances is much worse than just rooting the highlight tree under the root el)
<Rossen_> ack oriol
<TabAtkins> oriol: In the spec we resolved that ::backdrop now inherits from originating element
<Rossen_> ack emilio
<fantasai> TabAtkins: when I asked Anne about it, he didn't know why it was that way, so we fixed it
<TabAtkins> emilio: the backdrop case is similar in that the root el isn't in its inheritance chain, so if that's fixed it's good
<TabAtkins> emilio: But I stil lthink it'll be confusing for authors that they can't set further down the tree
<TabAtkins> fantasai: given that highlihgts don't inherit *anything else* from their originating element, i don't think it's unreasonble to assume the custom props inherit the same
<Rossen_> q?
<TabAtkins> fremy: some things are inherited...
<schenney> q+
<TabAtkins> emilio: currentcolor
<TabAtkins> fantasai: that's not inheritance
<Rossen_> ack delan
<TabAtkins> delan: I think we're getting sidetracked
<TabAtkins> delan: I was originally queued to say that all the breakage we've seen (and we've had dozens of bug reports) were about custom props on root
<ntim> q+
<TabAtkins> delan: So not a single instance reported of breakage from custom props elsewhere in the tree
<TabAtkins> delan: so for the compat issue this should be enough
<Rossen_> ack schenney
<TabAtkins> schenney: re: things coming from originating element, yes currentcolor
<TabAtkins> schenney: And next issue is about another case where we might take some info, still not a property tho
<TabAtkins> schenney: In *all* cases tho, for properties themselves it comes solely thru the highlight inheritance chain
<Rossen_> ack ntim
<TabAtkins> ntim: I see authors put custom props on shadow roots, I'd expect that to work
<emilio> To clarify, ntim means via `:host`
<astearns> +1 to accommodating :host as well
<TabAtkins> :host::selection should work, right?
<delan> does this proposal change anything around that?
<emilio> Having an editor custom-element doing something like `:host { --selection-color: red }` and use that from highlight pseudos seems reasonable...
<emilio> no
<emilio> q+
<TabAtkins> schenney: So if you put custom props on the shadow root, do you want it to have different values for the highlight than elsewhere on the page?
<Rossen_> ack emilio
<TabAtkins> emilio: It seems reasonable if you ahve an editor custom element to set custom props on :host
<TabAtkins> emilio: this is what I was talking about - it seems weird as an author that setting props on the root works but setting anywhere else doens't work
<ntim> I agree with emilio
<TabAtkins> emilio: I understand you can say :host::highlight but I think people wouldn't do that
<TabAtkins> emilio: they'd think if the root case worked, why wouldn't other cases work
<schenney> q+
<TabAtkins> q+
<TabAtkins> emilio: I understand this fixes the compat issue and there are ways to get the behavior you want, i just think it's not great
<Rossen_> ack schenney
<fremy> @ TabAtkins, I'll minute you
<TabAtkins> schenney: I just think the only option would be to go to dual inheritance
<TabAtkins> schenney: Which is a bad option too
<TabAtkins> schenney: So I'd prefer minimum compat maintanance
<emilio> ack TabAtkins
<iank_> i would prefer no double inheritance
<fremy> TabAtkins: I don't agree that this would be confusing for authors
<fremy> TabAtkins: having one single inheritance tree is usual
<florian> q?
<florian> q+
<fremy> TabAtkins: and I feel it would be even more strange if different properties inherit in different paths
<emilio> q+
<Rossen_> ack florian
<fremy> TabAtkins: I can see people stumbling on this once, of course, but they can look up and fix it with specific code
<TabAtkins> florian: going in the same direction, custo props are someitmes used to polyfill regular properties
<fremy> TabAtkins: so I don't see this being a long term confusion for authors
<TabAtkins> florian: Having them be more similar rather than more different probably is better
<Rossen_> ack emilio
<TabAtkins> emilio: i'm just not convinced authors would understand that highlight style inherits from other highlight pseudos and finally the root
<delan> q+
<Rossen_> ack dbaron
<florian> s/going in the same direction/going in the same direction as Tab/
<TabAtkins> dbaron: I have mixed feelings overall, but think im' reasonably sympathetic to TAb's argument about consistent model
<TabAtkins> dbaron: one of the thins we might require authors to do is write something both for the el and its highlights
<florian> s/, custo props are/., custo props are also
<TabAtkins> dbaron: which might b epainful because ther'es several highlight pseudos
<TabAtkins> dbaron: we might want a pseudo that refers to all the highlights.
<Rossen_> q?
<TabAtkins> dbaron: probably only useful for custom props
<TabAtkins> dbaron: would probably make this less painful for moving custom props around
<Rossen_> ack delan
<TabAtkins> delan: I think that's a good idea
<TabAtkins> delan: i also wanted to say that i'm not convinced that the proposed behavior would be too difficult for authors to understand
<TabAtkins> delan: and that it would be much worse than the legacy behavior where selection inherited from the originating el
<TabAtkins> delan: that model, which most brwosers currently have, also has unintuitive aspects
<TabAtkins> delan: for example, i set a selection color and background color on `p`, then the children don't have those colors. highight inheritance fixes that
<TabAtkins> delan: it is somethig authors could trip on but I think i generally agree with TAb, they'll trip over it once and then move on
<Rossen_> q?
<dbaron> (The example I gave was that authors could style element, element::all-the-higlight-pseudos { --custom-properties: values }.)
<TabAtkins> fremy: could we have an example of how you fix this with custom els?
<emilio> `:host, :host::highlight { --foo: red }
<TabAtkins> TabAtkins: you just need to shift them into the highlight tree as well
<TabAtkins> fremy: okay that's not that bad
<TabAtkins> Rossen_: so can we get to a resolution?
<emilio> Well, without dbaron's proposal you'd need `:host, :host::selection, :host::spelling-error, :host::grammar-error, :host::highlight(<foo>), :host::highlight(bar), ... { --foo: red }`
<fremy> sorry, didn't minute that
<TabAtkins> proposed resolution: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element
<TabAtkins> Rossen_: objections?
<TabAtkins> RESOLVED: highlight pseudos inherit across the highlight tree, and the root highlight inherits custom props from the root element

[fantasai]

This resolution has been overtaken by #7591 see #7591 (comment)