You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-conditional] Behavior of @supports(at-rule(@import)) #11116
The case of @charset is interesting, since according to the specification it is not an at-rule, although it usually looks and is perceived by authors as such. Would it be useful to add some special handling for this?
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. I can see four ways of dealing with that situation:
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.
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().
Adjust the @supports grammar to make @charset testable in a way that bypasses the situation. Some of the straw examples in [css-conditional-5] Feature detection for descriptors #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.
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.
Given that we're never extending or changing @charset in any way (the correct solution is "just use UTF-8, you maniac"), I don't care particularly much whether it's supported or not in @supports. Purely on cost-benefit, I think it's worth leaving it out; more or less nobody even thinks of @charset in the first place, and there is literally nothing you can do in response to any such test (since it's processed solely in a pre-processing step before parsing even occurs).
If there is ever a use-case for testing whether a given charset is supported by the browser in CSS, I'd be fine with defining a charset() testing function, but I just don't see how it's worth anyone's time to add special-case handling of @charset in @supports itself.
The CSS Working Group just discussed [css-conditional] Behavior of @supports(at-rule(@import)), and agreed to the following:
RESOLVED: at-rule(@charset) is invalid, but at-rule(@import) is allowed
The full IRC log of that discussion
<TabAtkins> kbabbitt: This is about what at-rules can be tested by at-rule(), partiuclarly those with positional requirements
<TabAtkins> kbabbitt: anders asked about @charset and @import
<TabAtkins> kbabbitt: proposed resolution is @import is testable, @charset is not, because @charset isn't actually an at-rule, it just looks like one
<TabAtkins> kbabbitt: from Tab's epxlanation, @charset is a legacy feature that authors shoudln't be using anymore
<lea> q?
<lea> q+
<TabAtkins> astearns: so proposed resolution is at-rule(@charset) is not testable, but at-rule(@import) is?
<astearns> ack lea
<TabAtkins> lea: does this apply just to at-rule(), or to the larger @supports-condition thing?
<TabAtkins> kbabbitt: this just applies to at-rule() right now
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: at-rule(@charset) is invalid, but at-rule(@import) is allowed
Activity
bleper commentedon Oct 31, 2024
The case of
@charsetis interesting, since according to the specification it is not an at-rule, although it usually looks and is perceived by authors as such. Would it be useful to add some special handling for this?bramus commentedon Nov 1, 2024
In #6966 (comment) I suggested to allow authors to either test for an at-rule’s name or an actual full at-rule.
That suggestion would also cover this case, as you could then check for someting like
@import … layer(…)and such.kbabbitt commentedon Jul 11, 2025
I don't see any reason why we shouldn't let authors test for support of
@import. It might not be useful in@supportsitself because you can't then condition an@importon it, but I could see it being useful either inCSS.supports(...)or@import ... supports(...).For
@charsetI think the same principle applies, except for what @bleper pointed out, which is that@charsettechnically is not an at-rule. I can see four ways of dealing with that situation: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.at-rule(), pretend that@charsetis 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@charsetand concludes it's not testable inat-rule().@supportsgrammar to make@charsettestable in a way that bypasses the situation. Some of the straw examples in [css-conditional-5] Feature detection for descriptors #2463 had noat-rule()function at all but rather tested things directly in@supportsjust 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.@charsetso 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
@charsetwould 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.tabatkins commentedon Jul 15, 2025
Given that we're never extending or changing
@charsetin any way (the correct solution is "just use UTF-8, you maniac"), I don't care particularly much whether it's supported or not in@supports. Purely on cost-benefit, I think it's worth leaving it out; more or less nobody even thinks of@charsetin the first place, and there is literally nothing you can do in response to any such test (since it's processed solely in a pre-processing step before parsing even occurs).If there is ever a use-case for testing whether a given charset is supported by the browser in CSS, I'd be fine with defining a
charset()testing function, but I just don't see how it's worth anyone's time to add special-case handling of@charsetin@supportsitself.kbabbitt commentedon Aug 4, 2025
Tagging for discussion at the upcoming F2F.
Proposal:
@importis testable but@charsetis not.Details in the explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtRuleFeatureDetection/explainer.md#non-goals
css-meeting-bot commentedon Aug 20, 2025
The CSS Working Group just discussed
[css-conditional] Behavior of @supports(at-rule(@import)), and agreed to the following:RESOLVED: at-rule(@charset) is invalid, but at-rule(@import) is allowedThe full IRC log of that discussion
<TabAtkins> kbabbitt: This is about what at-rules can be tested by at-rule(), partiuclarly those with positional requirements<TabAtkins> kbabbitt: anders asked about @charset and @import
<TabAtkins> kbabbitt: proposed resolution is @import is testable, @charset is not, because @charset isn't actually an at-rule, it just looks like one
<TabAtkins> kbabbitt: from Tab's epxlanation, @charset is a legacy feature that authors shoudln't be using anymore
<lea> q?
<lea> q+
<TabAtkins> astearns: so proposed resolution is at-rule(@charset) is not testable, but at-rule(@import) is?
<astearns> ack lea
<TabAtkins> lea: does this apply just to at-rule(), or to the larger @supports-condition thing?
<TabAtkins> kbabbitt: this just applies to at-rule() right now
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: at-rule(@charset) is invalid, but at-rule(@import) is allowed
[css-conditional-5] Spec at-rule() per CSSWG resolutions. w3c#2463, w…
Update at-rule() implementation and test to match CSSWG resolutions
Update at-rule() implementation and test to match CSSWG resolutions
Update at-rule() implementation and test to match CSSWG resolutions
Update at-rule() implementation and test to match CSSWG resolutions
[css-conditional-5] Spec at-rule() per CSSWG resolutions. #2463, #6966,
Bug 1994290 [wpt PR 55430] - Update at-rule() implementation and test…
Update at-rule() implementation and test to match CSSWG resolutions