[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.

[css-meeting-bot]

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

The full IRC log of that discussion

<emeyer> Topic: Custom properties on :root
<emeyer> github: https://github.com//issues/6641
<fantasai> -> https://github.com//issues/6641#issuecomment-1367600040
<emeyer> TabAtkins: Authors often define a big set of custom properties on the root element
<emeyer> …These reasonably might want to be used in highlight pseudos
<emeyer> …Currently, highlight pseudos don]t inherit from the normal DOM tree
<emeyer> …So they won’t see any of the stuff on the root
<emeyer> …The way around that is to have that big block have a selector of `:root, ::highlight`
<emeyer> …It’s a little weird and funky
<emeyer> …There are a few suggestions to address this
<emeyer> …One is to have some kind of at-rule allowing you to apply custom properties at a level higher than the root, which highlight pseudos could see
<emeyer> …Another is to change things so that highlight pseudos resolve their vars against the originating element
<emeyer> …Another is to say highlight inherits all custom properties from the root
<miriam> q+
<bramus> q+
<fantasai> ... and maybe all properties from the root
<emeyer> …I don’t like resolving var() differently
<emeyer> …I think it would complicate or break setting vars directly on highlights
<emeyer> …Inheriting from the root element has possibilies, but could cause cascade problems
<emeyer> …Inheriting just custom properties would be a little weird; it has minimal impact but it’s a new way of doing things that might have implementation problems
<emeyer> …Having a root-superior at-rule is also a new weird way to address this
<bramus> A use-case for inheriting only custom properties is `::backdrop`
<emeyer> …Not really sure how to approach this, but leaving as is where you have to select both root and highlights has some implementor objections over memory cost
<fantasai> bramus, why?
<emeyer> miriam: ::backdrop has a similar problem and it’s caused author problems, and articles are starting to pop up about having to address both
<bramus> Authors want it: https://kilianvalkhof.com/2023/css-html/backdrop-doesnt-inherit-from-anywhere/
<emeyer> …I like ::document or something like that, maybe could also respond to dark and light modes
<emeyer> …I’m not sure a document-selecto toggle could respond, though
<fantasai> bramus, but ::backdrop could just inherit from its originating element like all pseudo-elements, couldn't it? why would you want it to inherit from :root specifically
<Rossen_> ack miriam
<Rossen_> ack bramus
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to distinguish ::backdrop
<emeyer> bramus: There’s author demand for backdrop inheriting custom props
<emeyer> fantasai: That is a little different, as ::backdrop can inherit from its originating element and we should make it do that
<emeyer> …highlights have to inherit from a tree parallel to the document tree
<bramus> Spec says it doesn’t: https://fullscreen.spec.whatwg.org/#::backdrop-pseudo-element
<bramus> “It does not inherit from any element and is not inherited from.”
<emeyer> …I can see reasons why we might want an @document
<TabAtkins> Right, spec says it doesn't, but we can't see any reason *why* it shouldn't inherit.
<bramus> True :)
<argyle> q+
<fremy> +1 to inherit custom properties from :root, I think they are de-facto considered "global" by authors
<emeyer> …Downside to inherit-from-root is that you can only ever get variables from the root, not from other elements between root and the highlight
<TabAtkins> We asked about it in the repo but haven't gotten a response
<Rossen_> ack argyle
<emeyer> argyle: If I do define a bunch of vars on @document I could toggle them, but it’s a good place to put them
<fremy> q+
<emeyer> …The at rule would be the place things are originally defined, but can be changed later
<emeyer> fremy: I don’t see why a document is different form an initial value in this case
<dbaron> argyle, what about miriam's point about things like light/dark mode depending both on media queries *and* an attribute on the root that comes from a user-facing toggle
<emeyer> …Why would we ask authors define things in @document and then ask them to redefine later
<argyle> dbaron:
<emeyer> Rossen_: Any other thoughts?
<Rossen_> ack fremy
<emeyer> (silence)
<emeyer> Rossen_: Do we feel like we’re close to resolution, or should we just capture this and pick it up next week?
<fremy> fremy: (for the minutes, I mentioned how developers already assume :root variables are global, and we could acknowledge them as-is)
<argyle> dbaron: @document { --brand: hotpink }, and for dark mode `@media (prefers-color-scheme: dark) { :root { --brand: deeppink } } .dark { --brand: deeppink }` is what i was thinkin
<emeyer> fantasai: Is there any reason we should NOT have the highlight pseudo inherit from :root?
<emeyer> TabAtkins: If you put color: black on root and then inherit into the highlight, it would break the cascade
<emeyer> fantasai: I think that can work by having the highlight tree break inheritance
<emeyer> …You can have paired default highlight colors happen based on author style rules
<dbaron> s/highlight tree/UA style sheet/
<dbaron> s/inheritance/inheritance for color/
<fremy> @ argyle what is the value of @document here? @Property { initial } feels indentical (and, I believe, not that great in this case, you would want the deeppink in dark mode)
<TabAtkins> (I'm completely confused as to what fantasai is trying to say.)
<fantasai> s/highlight tree break inheritance/the UA stylesheet break inheritance/
<TabAtkins> (Either I, her, or both of us dont' understand what we're talking about.)
<emeyer> dbaron: A reason not to add it is that it still doesn’t solve the variables problem when they’re set on something other that the root
<emeyer> Rossen_: We’ll have to close here, the clock has run out

[fantasai]

To summarize earlier discussions, the three options that @tabatkins and I considered were:

1. Have the root highlights inherit from :root
2. Inherit custom properties from the originating element, other properties from the highlight parent.
3. Ignore custom properties on the highlight, have var() look up values on the originating element.

The downsides to each are:

1. Doesn't adopt custom property changes in subtrees.
2. Dual-inheritance is hard to implement
3. Setting a custom property and using it in the same place doesn't work on highlights

[delan]

Chromium just got a bug report about a breakage in the wild related to this issue, in GitHub’s code view for files. I’ve passed the report on to GitHub so they can work around it:

Code text selection broken in Chrome experimental (#2003892)

As for the most recent proposed options:

1. Have the root highlights inherit from :root — same concern as @Loirooriol, how would paired defaults work if the author sets a ‘color’ in one of the originating ancestors?
2. Inherit custom properties from the originating element — there is precedent for this with forced-color-adjust and with font properties, and Chromium has implemented those (with some memory usage penalty iiuc), but unlike custom properties, those properties aren’t applicable to highlights in the first place. i’m worried that doing it for applicable properties will make highlight pseudos more confusing for authors overall.
3. Ignore custom properties on the highlight — same concern as @tabatkins.

[css-meeting-bot]

The CSS Working Group just discussed [css-pseudo] Custom properties on :root.

The full IRC log of that discussion

<dael> fantasai: I guess this was question about can we use custom properties on ::selection etc.
<dael> fantasai: There's 3 approaches which each have a major downside
<fantasai> https://github.com//issues/6641#issuecomment-1404031937
<fantasai> body::selection inherits from html::selection
<fantasai> not from body itself
<dael> fantasai: 1. is to have the root::selection inherit from :root. Highlight pseudo elements inherit through their own tree. body::selection inherits from html::selection
<fantasai> :root::selection inherits from :root
<dael> fantasai: Option 1 is have root highlights inherit from root.
<dael> fantasai: Second is custom prop inherit from originating element where others inherit from highlight parent.
<dael> fantasai: 3rd is ignore custom prop on the highlight but when we use var look at originating
<dael> fantasai: Downside to 1 is if custom value changes in a highlight tree the subtrees won't know
<dael> fantasai: Downside to the second is inherit from 2 sources is hard to implement. I remember it was hard with first-line
<dael> fantasai: Downside to 3rd is if you set a custom property on the highlight and use it on the same property it won't look at the value you just set
<Rossen_> q?
<dael> fantasai: Question to the WG is which approach if any do we want to take
<dael> Rossen_: Opinions?
<dael> florian: I'm thinking having custom and regular properties inherit differently doesn't play nice with having custom prop polyfill regular ones. That would argue against option 2
<dael> florian: All options seem to have author-facing downsides so can't rule based on priority of constituency
<dael> Rossen_: Is there a path forward where we can adapt option 3 to work for highlight?
<fantasai> https://github.com//issues/6641#issuecomment-1404031937
<dael> fantasai: We can make all the options work, question of which has the least downsides
<dael> florian: Should we get author feedback and see what they'd find most or least helpful? I'd just be guessing
<dael> Rossen_: If that's what's holding us back we might
<dael> fantasai: Could be helpful to get feedback from sanketj team b/c more useful for custom highlights than ::selection
<dael> sanketj: I think we'll need to look into this a little bit more. No preference right now. We can follow-up
<dael> Rossen_: That doesn't inspire confidence to resolve today. We may have to come back to this once there are stronger opinions. Will that work fantasai?
<dael> fantasai: I don't think it's urgent, but good to figure out
<dael> Rossen_: If it's not ready for resolution let's remove the agenda+ and continue moving forward

[fantasai]

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