[css-syntax-3] Should `<declaration-value>` embed semantics?

[cdoublev]

This is a similar question than for #8795.

<declaration-value> represents any value that can be reasonably considered to look like a valid standard property. It excludes an omitted value for a custom property or @property/initial-value.

So now that consume a declaration (a syntax algorithm) should return nothing for a positioned {}-block, should <declaration-value> exclude that too? No, because a positioned {}-block is valid in a custom property value.

In my opinion, <declaration-value> (and <any-value>) should match zero or more tokens excluding <}-token>, <semicolon-token>, <delim-token> with a value of !.

From an author's perspective, it can be confusing that background-image: var(--url, invalid) is valid but not background-image: var(--url, url(bad token)), similarly as with --left: rgb( and --right: 0, 0, 0). Ok, using custom properties outside of CSS is not their primary use. But none of these declarations looks invalid.

Now it is probably too late to allow bad tokens, <)-token>, <]-token>, but maybe not zero token.

Most of the time, <declaration-value> (and <any-value>) is explicitly made optional ?. In env(), if(), inherit(), random-item(), var(), @property/initial-value, custom properties, etc.

It is not optional as a custom function argument but --mixin(255,, 0) might be useful with @function --mixin(--r: 0, r: 127, b: 0) { ... }. It is also not optional for @function parameters, param(), first-valid(), but I do not want to argue why it could also be optional and make this comment longer than it already is.

[tabatkins]

Sorry, I'm not entirely certain what is being asked for here.

From an author's perspective, it can be confusing that background-image: var(--url, url(bad token)) is valid but not background-image: var(--url, invalid)

Did you mean invalid here? Or just mean to put them in the other order? The first one is invalid, the second one is valid.

url() is just a weird legacy situation for a few reasons. I'd prefer to keep bad-urls invalid.

CSS's rules about matching the paired delimiters ()[]{} are also pretty sacrosanct and valuable to preserve. I don't want to allow them to show up unpaired, and definitely don't want to allow them to match up across different variable substitutions.

So all that's left is whether <declaration-value> can validly match nothing. It currently requires something, and appending a ? allows it to match nothing. If we changed it to allow matching nothing, tho, then nothing we could put into the grammar would allow us to indicate it has to match something; it would always have to be a prose condition.

[cdoublev]

background-image: var(--url, url(bad token)) is valid but not background-image: var(--url, invalid)

Did you mean invalid here?

Yes. Edited.

Sorry, I'm not entirely certain what is being asked for here.

I am troubled by the difference between the value ranges represented by <declaration-value> and declaration values... (please read below if I failed to explain this)

CSS Syntax defines <declaration-value> as representing the entirety of what a valid declaration can have as its value. That is not true for custom properties and @property/initial-value, which allow zero token.

This is also not true when looking at consume a declaration, which accepts zero token for its value. When it is defined with a forgiving grammar (@font-face/src), it also accepts bad tokens, which are preserved in the token stream [...] to define more fine-grained error-handling than just dropping an entire declaration or block. To my surprise, browsers do not accept bad tokens in declaration values containing an arbitrary substitution (#11315).

Now I understand the reasons you mentioned for not changing the grammar of <declaration-value>. So I am not asking for that, nor for this production to be renamed, but perhaps for some clarification.

It represents the entirety of what a valid declaration can have as its value.

Note: the declaration value of some properties or descriptors may be defined in other specs to accept these invalid tokens or zero token (like custom properties).

[tabatkins]

I'm fine <declaration-value> representing all possible tokens in a declaration's value. We rarely (if ever?) make a production capable of being fully empty; that's (almost?) always instead left to the spot that uses the production to add a ? if it wants.

[cdoublev]

SGTM too.

[cdoublev]

<declaration-value> represents the entirety of all the possible tokens that a valid declaration can have as its value.

However, I would still add a note if this allows @font-face/src to include bad tokens, as in Chrome but not Firefox. And if they must be allowed, I assume they must also be allowed in the prelude of @media, as in Chrome and Firefox, and in :is(), as in Chrome but not in Firefox.