- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Jan 2025 11:02:15 +0000
- To: public-css-archive@w3.org
I realized that browers accept "bad tokens" in [`@font-face/src`](https://drafts.csswg.org/css-fonts-4/#src-desc), whose grammar is forgiving, and also remembered about this [non-normative note](https://drafts.csswg.org/css-syntax-3/#preserved-tokens) 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). -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11315#issuecomment-2567598772 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 January 2025 11:02:16 UTC