[css-values-5] Should an empty {} match <declaration-value> and <any-value> in functions?

[cdoublev]

Considering the emphasized part below, I would say no because <declaration-value> and <any-value> require one or more tokens:

If it does start with a "{" token, then the production matches just the {} block that the "{" token opens. It represents the contents of that block, and applies whatever specific restrictions it defines for itself to those contents, ignoring the {} block wrapper.

https://drafts.csswg.org/css-values-5/#comma-containing-productions

However, it matches <whole-value>, right? No use case in mind, I just want to be sure.

[cdoublev]

I cannot see how fn({}) could reasonably match fn(<declaration-value>?), since the argument does not match <declaration-value> but is also not omitted (the input is not fully consumed). ? is not part of the comma-containing production, unless otherwise specified (excluding other multipliers).

And it seems a bit odd that color: first-valid({}, red) should be invalid because its arguments do not match <declaration-value>#.

[Loirooriol]

I guess {} matches <declaration-value>? but not <declaration-value>

[cdoublev]

So a {}-block in a function at the location of a comma-containing production, would be somewhat similar to a whitespace. It is not represented in the syntax definition. It can be present in the input and change the syntax of the contents. But when it is alone, it is as if nothing is present. Alright.

[cdoublev]

Matching an optional production with a "concrete" token seems somewhat unusual for a language parser but in hindsight, I think no clarification is needed. first-valid() is intentionally defined to accept non-empty arguments, so there is no reason for an author to expect first-valid({}, valid) to be valid if it already knows first-valid(, valid) is not.

So closing as question answered.