[css-fonts] [palettes] Should calc() or var() be allowed inside @font-palette-values?

[litherum]

Should authors be able to do things like base-palette: calc(3 + 4);?

This increases the implementation complexity, and I can't think of any use cases for it (since variables are not available in at-rules).

[Loirooriol]

Isn't calc() available in descriptors for free, reusing the machinery from properties? Firefox and Chromium accept calc() in @counter-style's pad.

[svgeesus]

Computed GOTO considered harmful.

Palette numbers are font-specific and are determined by inspecting the font, so at that point they are known and should be considered constant values. Doing computation on them has no realistic use-case that I can see.

Using calc() to calculate the number of padding symbols to use for multi-digit counters on the other hand is much more reasonable.

[tabatkins]

To be fair, env() functions are available, and if we (I) ever properly define user-defined env constants, they could reasonably be piped into here.

I'm uncomfortable with special-purpose restrictions like this; they make the language more complex to learn and use. A <number> should be a <number> anywhere it shows up, ideally.

[o-t-w]

I can't think of a use case for calc().
Support for var() is very important. It's common to use CSS custom properties to store color values. It's overwhelmingly likely that people will want to use these color variables in conjunction with @font-palette-values.

The following code doesn't work in Safari Technology Preview 134.

:root {
    --yellow: lch(93% 132 94);
}

@font-palette-values --Lurid {
    font-family: bungee;
    base-palette: 0;
    override-colors:
        0 lch(76% 132 159.026),
        1 var(--yellow);
}

.lurid {
  font-palette: --Lurid;
 font-family: 'bungee';
}

Changing CSS custom properties with Javascript is an easy way to do theming. If somebody wanted a color font to be different colors depending on dark or light theme, for example, being able to update a custom property with javascript would seem like the simplest approach for web developers.

[faceless2]

Funny, we've literally just hit the same question about 30 minutes while bring our implementation up to date with recent changes.

I agree with @o-t-w; in particular I think override-colors is an area where var() is very likely to be wanted by authors, although I realise that it's more complicated than normal as it's used in an at-rule rather than a regular declaration.

We've implemented it as a special case, reevaluating the @font-palette-values declarations at the point the font is used to expand var(). But then for print output we only have to do it once, so it's not so bad. I don't know how this would work for browsers, where the var could conceivably be animating

[litherum]

As long as variables in the palette are evaluated in the context of the root element (which would satisfy @o-t-w’s example), and not the element they’re applied to, implementation shouldn’t be too difficult.

The thing that would make implementation difficult is if different elements that reference the same @font-palette-values rule end up getting different palettes because it’s evaluated differently each time.

[faceless2]

This is also related - web-platform-tests/wpt#31517. None of your recent tests covered currentColor so I've added a couple with this PR.

If you're going to support currentColor - and I think it's important that we do - then you're necessarily going to be reevaluating these palettes at the time of use.

[litherum]

Yeah - it's important to us that the colors inside the @font-palette-values rule are not re-evaluated at the time of use, but it's okay if currentColor will be re-evaluated at the time of use. Those are implemented using different mechanisms for us. Specifically, the palette of colors is considered a font creation parameter, but currentColor isn't.

[drott]

CC @andruud

[andruud]

Allowing calc() does not really increase implementation complexity, and env() seems reasonable to allow as well. (But then let's consider doing that more generally, and not as a special thing for this).

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.

[drott]

Filed as #6931, let's continue discussing var() there.