- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jan 2024 20:15:19 +0000
- To: public-css-archive@w3.org
`--foo:hover { color: blue; } var(1);` will fail to parse as a valid declaration, and instead attempt to be parsed as a qualified rule. > So I do not understand why checking nesting is needed In a nested context, a `--foo: ...` is *probably* a declaration, so consuming the whole thing to next the same-level semicolon is likely to be the correct behavior. At the top level, properties aren't allowed; if you've written `--foo:...` it's much more likely you are trying to write a rule. You don't see many stray `color: blue;` declarations at the top level of a stylesheet, after all. So we should consume just a rule-worth of tokens; that's more likely to match what the author intended. Plus, since declarations aren't valid at the top level, it's very unlikely that a top-level semicolon will appear *at all*, so a stray `--foo:...` would likely consume *the entire rest of the stylesheet* if it was treated as a declaration. > Do you mean that `--foo: var(<not-custom-property-name>)` should fail to be consumed as a declaration? Correct. That's step 9 of ["consume a declaration"](https://drafts.csswg.org/css-syntax-3/#consume-a-declaration) > it seems inefficient to retry parsing a declaration as a rule because its value was invalid according to the grammar. Sure, it would be inefficient. But you don't actually have to try, you just have to act identically to an impl that *did* try. The vast majority of the time you can just quit immediately, or at least very quickly. See the impl notes at the end of ["consume a block's contents"](https://drafts.csswg.org/css-syntax-3/#consume-a-blocks-contents), which offers guidance about this exact topic. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9336#issuecomment-1877703421 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 4 January 2024 20:15:21 UTC