[css-syntax-3] Potentially missing a "parse error" specifier in "consume a URL token"?

[JasonTheKitten]

• please tag the issue title with the spec's shortname, like [css-foo]
  (this is the name from the spec URL, without a level number unless the issue is specific to that level).
  If you're proposing a new feature that doesn't obviously fit in an existing spec, skip this part — don't make something up.

[css-syntax-3]

• please be specific (in the title and issue) about what you want to change:
  “make it better” means different things to different people!

The specification has a paragraph that is as follows:

1. If the next input code point is \u0029, we are successful and return the URL token
2. If we have reached the end-of-file, we record a parse error and return the URL token
3. Otherwise, we consume the remnants and return a bad URL token

In the third case, we have obviously run into poor, malformed syntax. However, the spec never actually says that a parse error is given in this case, so a spec-compliant validator would not actually report a problem. This leads me to think that we are missing a parse error.
(Note: there is a parse error defined for the second case, but the way the spec is worded it does not apply to the third case)

• please link to the spec section you're talking about, or at least the spec

CSS Syntax Module Level 3

[cdoublev]

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

This may explain why no parse error is "emitted" in consume a URL token but it is not clear to me as well.

[JasonTheKitten]

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

This may explain why no parse error is "emitted" in consume a URL token but it is not clear to me as well.

If this is the case, then it would mean that the spec is inconsistent.
In some spec slightly below it, a parse error is explicitly mentioned to be "emitted" as well as a bad-url-token being returned.

[cdoublev]

(Generalizing this issue to all occurrence of "parse errors".)

Another case is consume a qualified rule, which mentions } as a parse error, whereas consume an at-rule does not.

Explicitly mentioning (and processing) these "bad and orphan" tokens as parse errors in all the algorithms would make them unnecessarily complex imo. Conversely, being consistently implicit might be even more confusing: (edit: there is actually no example of this, as all tokens below should be explicit parse errors)

• U+0022 QUOTATION MARK (")
• U+0027 APOSTROPHE (')
• non-printable code point
  This is a parse error. Consume the remnants of a bad url, create a <bad-url-token>, and return it.
• U+0028 LEFT PARENTHESIS (()
  Consume the remnants of a bad url, create a <bad-url-token>, and return it.

Being explicit only when necessary therefore seems to be a good compromise.