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

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

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?

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

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.

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 */
}

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

@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

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.

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

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!

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?

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?

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

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

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

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.

New Chromium bug reports:

• 1444107 (webdev with own repro, no mention of GitHub)
• 1442944 (on GitHub)

We can make the root highlights inherit custom properties from :root, like we did for ‘font-size’ in #7591.

This avoids the interaction with paired defaults under option 1, the problems with dual inheritance under option 2, and the inability to set variables in highlights under option 3, while fixing the many compat issues we’ve seen in the wild.

Potential downsides:

• We would still be breaking compat for custom properties set elsewhere in the tree — this seems purely theoretical, since all of the bug reports we’ve seen so far are about custom properties on :root

• It’s a special case that makes :root behave differently — this is not unusual for CSS, see also ‘font-size’ in highlights, css-background #root-background, css-overflow #overflow-propagation, and the initial containing block

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.

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