[css-values-5] Should <whole-value> functions be parsed before the declaration value range?

[cdoublev]

CSS-wide keyword parsing should kick in first because --custom: initial should result to --custom being declared to its initial (guaranteed-invalid) value rather than the <ident-token> for initial (the result from matching against its value definition).

Arbitrary substitution parsing should then kick in before the value range because --custom: var(1) should be invalid. They should be parsed before <whole-value> because display: var(--empty) first-valid(block) should be valid (at parse time, at least).

Should --custom: first-valid(not, whole) value be valid?

[Loirooriol]

Unregistered custom properties just tokenize, except for a few things like var() and env(). So:

• If first-valid() is a normal function, it's accepted, as a token.
• Otherwise I guess it's invalid.

I don't see any reason to treat it specially, since unregistered custom properties accept almost everything?
I don't think it's likely that people will want --foo: first-supported(var(b), var(--b)) to behave as --foo: var(--b) because --foo: var(b) is invalid.
I think it's more likely that people will want to defer the resolution of first-supported, e.g.

:root {
  --color: first-supported(color(brand-new-color-space, ...), cyan);
}
.foo { color: var(--color) }
#bar something { color: var(--color) }

[cdoublev]

Unregistered custom properties just tokenize, except for a few things like var() and env().

I have not considered this option. So --custom: first-valid(not, whole) value is valid but not --custom: first-valid(1) var(--empty, var(invalid)), and a CSS parser should therefore not try matching <whole-value> as a replacement for a custom property value, but only for standard properties?

Even if first-valid(not, whole) value is guaranteed to be valid in any declaration value, it would probably not be usefull to make it invalid at parse time also for a custom property value. It just seems more consistent though.