- From: Kevin Babbitt via GitHub <noreply@w3.org>
- Date: Fri, 11 Jul 2025 22:17:11 +0000
- To: public-css-archive@w3.org
I don't see any reason why we shouldn't let authors test for support of `@import`. It might not be useful in `@supports` itself because you can't then condition an `@import` on it, but I could see it being useful either in `CSS.supports(...)` or `@import ... supports(...)`. For `@charset` I think the same principle applies, except for what @bleper pointed out, which is that [`@charset` technically is not an at-rule](https://drafts.csswg.org/css-syntax/#charset-rule). I can see three ways of dealing with that situation: 1. Accept the situation as-is, which would make it not supported when tested with `at-rule()` since there is no at-rule named `@charset`. I don't like this option because it seems to prioritize architectural purity over author utility, but I could be swayed to it with a strong enough argument for why other options wouldn't work. 2. In the context of `at-rule()`, pretend that `@charset` is an at-rule. This is author-friendly and less churn on existing specs, but it could lead to confusion in the other direction if someone reads the spec for `@charset` and concludes it's not testable in `at-rule()`. 3. Adjust the `@supports` grammar to make `@charset` testable in a way that bypasses the situation. Some of the straw examples in https://github.com/w3c/csswg-drafts/issues/2463 had no `at-rule()` function at all but rather tested things directly in `@supports` just like property:value pairs, e.g. `@supports (@charset)`. From reading the discussion minutes, I got the impression that some folks preferred having a function and others didn't object, so that's what the group resolved on, but we could revisit that decision. 4. Change the specification of `@charset` so that it would be considered an at-rule. Based on my read of the spec, I'm imagining this as something like a "restricted at-rule" that preserves the existing syntax constraints but simply removes the technicality that it's not an at-rule for sake of clarity. Options 2-4 also raise another question: If we accept the proposal in #6966 to add a third form that takes an entire at-rule, for `@charset` would we apply the same strict parsing as for actual use at the top of a stylesheet? I would think "yes," because otherwise an author might get a "supported" answer if e.g. there there's extra whitespace present in their supports condition, but then if they copy-paste that condition to the top of a new stylesheet suddenly it wouldn't work, and it would not be clear why. -- GitHub Notification of comment by kbabbitt Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11116#issuecomment-3064024150 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 11 July 2025 22:17:11 UTC