[css-fonts] [palettes] Disallow usage of var() in `@font-palette-values`

[drott]

In https://github.com/w3c/csswg-drafts/issues/6631#issuecomment-1004861176 @andruud suggests that usage of var() inside @font-palette-values is unconventional compare to the usual usage of var().

We may want to disallow var() usage in @font-palette-values or - if that's not acceptable - specify it differently, so that it's evaluated in the element's context if really needed / possible.

@andruud's feedback:

However, allowing var() would introduce an awkward and unwanted dependency on the computed style of the root element, which we should probably avoid. It also seems a bit unfortunate from an author's standpoint to deviate from the computed-value-time/element-centric nature that var() currently has, and decide that it works in a different way here.

Going in the "author env()" direction seems more approachable, depending on its shape. There are other reasons we may need things like that as well, e.g. #6641.

Spec text after ee8dada50f9:

Functions such as ''calc()'', ''var()'', and ''env()'' are valid within the braces of a ''@font-palette-values'' rule. They are evaluated within the context of the root element. Relative units are also evaluated within the context of the root element.

[drott]

CC @tabatkins

[tabatkins]

Anders points to #6641; in there I say that "author env()" isn't great because it means that, in many cases, you'll be forced to duplicate the same information in both places. Most variables are document-global anyway, so the choice of whether you do it as a var()-on-root or author-defined env() would be mostly arbitrary, and having to decide between the two wouldn't be ideal.

I'm supportive of the idea Anders hit in that thread, of allowing these sorts of non-element cases to use the initial value of custom properties, which are provided by @property. That satisfies the use-case of "author-level env()" while simultaneously continuing to act as a normal custom property. I think that would be appropriate here as well.

[LeaVerou]

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.

[LeaVerou]

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

[litherum]

I'm operating under the following constraints:

1. It should not be possible for different elements within a document to resolve the same font palette to different colors
2. It seems reasonable that an author would want to specify a color from their page's color theme within a font palette. Authors often store their page's color theme in CSS variables (on the root).

Beyond satisfying those 2 constraints, I have no opinion how this gets resolved.

[tabatkins]

No worries, this is being discussed in #6641 for a general solution.

[svgeesus]

So, should we close this issue and use whatever general solution emerges from

• 6641

[yisibl]

This article also expresses a desire to support var().