- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 Jan 2024 08:01:42 +0000
- To: public-css-archive@w3.org
I do not see in which nested context `--foo:hover { color: blue; } not-semicolon` would not be *consumed* as a (valid) declaration. So I do not understand why checking `nesting` is needed (in [*consume a qualified rule*](https://drafts.csswg.org/css-syntax-3/#consume-qualified-rule), cf. previous comment) instead of consuming `{}` *indifferently* whether the consumed rule is nested or not. --- (I'm trying to guess from here, if that helps explain it to me what I am missing.) From the note titled *What's this check for* below the *consume a qualified rule* algo (and also in the previous comment): > This ensures that `--foo:hover { color: blue; }` is consistently invalid everywhere [...] Does it mean that this is consistently an invalid *rule* everywhere? > Authors can write a custom property that takes a `{}-block` in its value, even combined with other thing; if that custom property is then invalid (due to an invalidly-written `var()` function, for example), [...] Do you mean that `--foo: var(<not-custom-property-name>)` should fail to be *consumed* as a declaration? [2.2 Error Handling](https://drafts.csswg.org/css-syntax-3/#error-handling) says that the grammar must be checked after *each* construct is parsed, but it is non-normative and it seems inefficient to retry parsing a declaration as a rule because its value were invalid according to the grammar. I may have misuderstood https://github.com/w3c/csswg-drafts/issues/8834#issuecomment-1677876075, ie. what it means to check that a declaration or rule is *valid in the context* (which [I think](https://github.com/w3c/csswg-drafts/issues/8834#issuecomment-1685266923) is not required anymore, btw). -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9336#issuecomment-1876669855 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 08:01:45 UTC