- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 16:53:03 +0000
- To: public-css-archive@w3.org
Yup, this looks like just a mistake; I didn't mean for this hungry behavior to apply at the top-level. The *intention* of the hungry behavior is that it's already *very* difficult for custom properties to *actually* ever be invalid, so an "ambiguous rule" like `--foo:hover {...}` would *virtually never* fail the "looks like a declaration" test and actually parse as a rule. To avoid that being a super rare case, I just catch it in the "consume a rule" algo and force it to continue to act like a custom property. But since custom props (or any props at all) can't exist on the top level of a stylesheet, there's no reason to worry about it. That is, `--really-a-prop:hover and-more-weird-values` is just unreasonable to interpret as a property at the top level of a stylesheet. So yeah, I propose that we do indeed guard against this. Specifically, in <https://drafts.csswg.org/css-syntax/#consume-a-qualified-rule>, in the `{-token` branch, if we see something that looks like a custom property, then we behave differently based on whether it's nested or not: if nested, we do the current behavior (force it to be a custom property and throw it away), if not nested, we just consume the {} block and then throw it away. This maintains the constant I want to maintain about where `--foo:hover {...}` rules are allowed (nowhere), and avoids eating an entire stylesheet. Agenda+ to confirm this with the WG. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9336#issuecomment-1719806755 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 16:53:06 UTC