[css-syntax-3] Should a declaration value be consumed as a <declaration-value>?

[cdoublev]

In consume a declaration, it is currently consumed as a (unrestricted) list of component values.

But in the current version of Chrome and FF (at least), it seems to be consumed as a <declaration-value>:

<style>
  style {
    color: var(--color) url(bad url);
    color: var(--color) );
    color: var(--color) !;
  }
</style>
<script>
  document.styleSheets[0].cssRules[0].cssText; // style {}
</script>

I could not say whether CSS2 also considered these declarations as invalid.

CSS Syntax 3 is less restrictive, which can change the declared value:

<p style="color: green; color: var(--opacity) url(bad url);">
  black per spec,
  otherwise green
</p>

[cdoublev]

Chrome and FF (non-exhaustive) also do not accept a declaration value containing !important followed by any component value other than a stop stoken (; and/or }).

<style>
  style {
    color: !important var(--color);
  }
</style>
<script>
  document.styleSheets[0].cssRules[0].cssText; // style {}
</script>

<declaration-value> does not accept ! but I hope it is ok if I generalize this issue to "there is a gap between what consume a declaration says and what browser actually do".

This specific mismatch could be fixed generically in step 6, by saying that the next token should be a stop token or the stream should be empty.

[cdoublev]

I realized that browers Chrome accepts "bad tokens" in @font-face/src, whose grammar is forgiving, and also remembered about this non-normative note about them:

Note: The tokens <}-token>s, <)-token>s, <]-token>, <bad-string-token>, and <bad-url-token> are always parse errors, but they are preserved in the token stream by this specification to allow other specs, such as Media Queries, to define more fine-grained error-handling than just dropping an entire declaration or block.

So declaration values must not be restricted to <declaration-value> while consuming them (before grammar validation), and color: var(--custom) ]; must be valid at parse time, if not specified otherwise.

As reported in #7987, these parse errors are not always explicit in the CSS Syntax algorithms, which is confusing. So I assume that bad tokens must be preserved in the token stream, and also in preludes and declaration values, except <}-token>.

Alternatively, I guess a CSS parser can consume and validate each component value one after the other, which presumably requires making consume a function and consume a simple block context aware, so that style:is( ] , .valid) {} can be valid (because the grammar of :is() is forgiving).