- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 09:02:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-conditional] `@supports-condition`, for larger feature queries and named reuse``, and agreed to the following:
* `RESOLVED: Draft this into the same spec as @custom-media`
* `RESOLVED: Add Lea as editor of that spec`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> lea: We have a bunch of issues around "how do we express this thing in @supports"<br>
<fantasai> lea: we're creating a parallel syntax to describe CSS syntax<br>
<fantasai> lea: makes it difficult to design, and also confusing for authors who don't understand CSS syntax well<br>
<fantasai> lea: e.g. authors don't understand difference between descriptor and property<br>
<fantasai> lea: What if you could just stuff an entire block of stuff into a condition and ask if it's valid?<br>
<fantasai> lea: ...<br>
<TabAtkins> (thanks to anders, too, for css parsing being robust)<br>
<fantasai> lea: CSS parsing is robust enough to handle all sorts of invalid things, so what if we had something like @supports-condition where you can stuff whatever you want<br>
<fantasai> lea: could be a selector and rule, or properties, or any at-rule, and you would check if it's valid<br>
<fantasai> lea: could even check at-rules inside at-rules<br>
<fantasai> lea: avoids needing to invent a meta-syntax for everything<br>
<fantasai> lea: and also gives us more complex feature queries<br>
<fantasai> lea: parallel to custom-media<br>
<fantasai> lea: also provide maintainability benefit<br>
<fantasai> lea: we still need special functions for things that don't cause a parse error but need to check support<br>
<fantasai> lea: Even at-rule() could have simple version for does this at-rule exist<br>
<fantasai> lea: but for more complicated things, better to say the syntax you're testing<br>
<fantasai> lea: some issue raised<br>
<fantasai> lea: but seems reasonable you might want to combine named feature queries with inline feature queries<br>
<fantasai> lea: also, should be able to name inline queries<br>
<fantasai> lea: so rule could have block syntax and non-block syntax<br>
<fantasai> lea: also question of how do you combine named feature queries with inline queries to create higher-level queries<br>
<fantasai> lea: maybe useful for v2<br>
<fantasai> lea: main issue is that condition token requries parens around condition<br>
<fantasai> lea: so either have two syntaxes, e.g. @supports --named-condition { ...}<br>
<fantasai> lea: or a parenthesized version<br>
<kbabbitt> q+<br>
<fantasai> lea: do we allow plain --ident syntax? or parenthesize?<br>
<fantasai> lea: I think it's common to parenthesize only when need to group, not in advance<br>
<fantasai> lea: kbabbitt: raised issues wrt at-import and supports conditions<br>
<TabAtkins> q+<br>
<fantasai> lea: maybe you defer loading until the name is defined<br>
<fantasai> lea: multiple conditions with same name, last one wins<br>
<fantasai> lea: question of ordering wrt @import<br>
<fantasai> lea: but we should have a JS method also<br>
<fantasai> lea: JS method could even give you more info<br>
<astearns> ack kbabbitt<br>
<fantasai> kbabbitt: I like the set of ideas presented here<br>
<fantasai> kbabbitt: I have some reservations around the edge cases<br>
<astearns> q+<br>
<fantasai> kbabbitt: I do agree that we still want the simple at-rule method on @supports for simple cases if an at-rule is recognized at all<br>
<fantasai> kbabbitt: useful for cases such as @starting-style where you don't want to bother setting up extra context<br>
<fantasai> kbabbitt: for JS query, just have a method that accepts a fragment of CSS<br>
<fantasai> kbabbitt: other interesting case that came up is MQ, where the parsing is forgiving for cases where particular media feature can be parsed successfully but not supported<br>
<fantasai> kbabbitt: need some additional handling there<br>
<lea> q?<br>
<fantasai> kbabbitt: one other thing, in terms of dealing with supports conditions on import, what could happen if author adds supports condition later<br>
<lea> q+<br>
<fantasai> kbabbitt: doing it with media queries already<br>
<fantasai> kbabbitt: maybe some weirdness there<br>
<andruud> q+<br>
<fantasai> kbabbitt: overall, I like it as a direction. I think it's simple and more extensible than adding functions for support<br>
<SebastianZ> q+<br>
<astearns> ack TabAtkins<br>
<noamr> q+<br>
<fantasai> TabAtkins: +1 to what kbabbitt said, good idea in general<br>
<fantasai> TabAtkins: question about parsing context of stuff inside the rule<br>
<fantasai> TabAtkins: proposal make sit as if you're inside an existing style rule, so immediately test for properties<br>
<fantasai> TabAtkins: Need to be careful so that those things not allowed inside a style rule would work<br>
<fantasai> TabAtkins: issues wrt cyclic resolved by earlier discussion about define-before-use<br>
<matthieud> q+<br>
<andruud> q-<br>
<fantasai> TabAtkins: Final bit about using inside an @import, I think we should have the new custom whatevers to have a JS API so you can register them in JS<br>
<fantasai> TabAtkins: and that can be globally available<br>
<SebastianZ> +1 on kbabitt's points<br>
<astearns> ack astearns<br>
<fantasai> TabAtkins: treated as appearing before start of all styles<br>
<fantasai> astearns: I like the idea, a bit skeptical of the promise that this will save us from inventing other syntaxes<br>
<fantasai> astearns: places where we do parse things more liberally<br>
<fantasai> astearns: I think we should have this, but I think we're going to keep adding microsyntaxes anyway<br>
<fantasai> astearns: and this reminds me of conversations with miriam and she says "this is another mixin isn't it"<br>
<fantasai> astearns: various ways to name a block of CSS, can we have a generic solution for all of them<br>
<astearns> ack fantasai<br>
<lea> scribe+<br>
<lea> fantasai: For @import, we should allow declaring these conditions as well as custom media, before @import so they can be used for conditional imports<br>
<lea> fantasai: we already allow this for layer order<br>
<lea> fantasai: for exactly this reason, you need to be able to control the layering of the imports, so there's precedent<br>
<lea> fantasai: wrt this the context opened up by the custom supports condition should be a top level context, if you want to be inside a style rule, be inside a style rule<br>
<kbabbitt> +1 to it being a top-level context<br>
<lea> fantasai: if you want to test declarations that's already easy for @supports<br>
<kbabbitt> in fact, I'd go slightly stronger and say it should be "brand new stylesheet context" so various features of @import can be tested<br>
<lea> fantasai: if we want to do inline @supports opening bracket should already get you in that context<br>
<lea> kbabbitt +1<br>
<noamr> q-<br>
<fantasai> @supports ({ top-level context check thing }) { stuff }<br>
<fantasai> equivalent to<br>
<fantasai> @supports-condition --foo { top-level context check thing };<br>
<emilio> q+<br>
<astearns> ack lea<br>
<fantasai> @supports --foo;<br>
<fantasai> s/;/ { stuff }<br>
<TabAtkins> (we avoided inlining rules into @supports before because it's just unreadable. nothing wrong with it parsing-wise, it's just kinda ridiculous to actually look at)<br>
<fantasai> lea: I agree wrt supporting these declarations prior to @important<br>
<kbabbitt> s/@important/@import/<br>
<lea> s/ @important/ @import/<br>
<fantasai> lea: for testing media query features that are parsed vs supported, same as font-tech(), still need microsyntax<br>
<fantasai> lea: but not having to create a new one for everything is a gain.<br>
<fantasai> lea: For Tab, I was going to say, I'd have least constrained context<br>
<fantasai> lea: but suggested that should be most unconstrained existing context, i.e. start of new style sheet<br>
<fantasai> lea: some things are less easy, e.g. declarations, but like fantasai said it's easy to do already<br>
<fantasai> lea: consistency of using existing well-defined context outweighs being able to nest raw declaraitons<br>
<fantasai> lea: Alan said we'll still need functions that parallel syntax, I don't see why except as shortcuts<br>
<fantasai> lea: we don't even need a descriptor arguemnt for at-rule, just test the at-rule<br>
<fantasai> lea: it cuts down scope very much for these functions, even when a convenience<br>
<fantasai> lea: so I do think we should try to make sure verything we want to test for can be done<br>
<fantasai> lea: it is interesting idea to combine with mixins, but some things aren't allowed in mixins<br>
<fantasai> lea: and here everything is allowed<br>
<TabAtkins> +1, this reduces the value of new testing functions from "we need this to make it testable at all" to just "this will be a common test and it's inconvenient to write out fully"<br>
<fantasai> fantasai: yea, I think they have to be separate. Mixins take argument,s bunch of other stuff<br>
<astearns> q?<br>
<noamr> q+<br>
<astearns> ack SebastianZ<br>
<fantasai> TabAtkins, depends how you format your source code really<br>
<fantasai> SebastianZ: I think this should be specced and implemented ASAP<br>
<fantasai> SebastianZ: we added at-rule() in 2022 and still not in a spec!<br>
<fantasai> SebastianZ: in the meantime many ne at-rules which can't be tested for<br>
<fantasai> SebastianZ: I'm totally for this @supports condition<br>
<astearns> ack matthieud<br>
<fantasai> matthieud: right now, @supports selector() doesn't take context into account<br>
<fantasai> matthieud: e.g. relative selector won't check out<br>
<TabAtkins> (I fell really behind around the end of my full-WFH isolation, sorry about that.)<br>
<emilio> q-<br>
<astearns> ack noamr<br>
<fantasai> noamr: Maybe this could be an extension of custom-media, rather than another thing<br>
<fantasai> noamr: idk if this is too much, but feels like we're having a lot of tidbits of names that are used in the same name<br>
<fantasai> noamr: that'll simplify things<br>
<lea> q?<br>
<fantasai> noamr: custom-media is just an at-rule with a semicolon, not complicated<br>
<astearns> ack fantasai<br>
<lea> fantasai: at supports conditions and @media are doing largely the same thing, declaring a name for a condition, and should be more consistent<br>
<lea> q+<br>
<astearns> ack lea<br>
<fantasai> s/at supports/@supports-condition/<br>
<fantasai> s/@media/@custom-media<br>
<TabAtkins> They should be `@custom-supports`. Unless we can finally agree on `@when` and make them mergeable...<br>
<fantasai> lea: Value in harmonizing, but my understanding of @custom-media is defining an alias over what you can do in media<br>
<fantasai> lea: whereas this allows new stuff<br>
<SebastianZ> +1 on TabAtkins<br>
<fantasai> fantasai: I was suggesting to be able to do it inline also<br>
<fantasai> lea: Seems awkward. As long as it's not the only way.<br>
<fantasai> TabAtkins: Until we have merged conditional, I think they should be separate at-rules<br>
<fantasai> fantasai: They should at least have similar naming pattern<br>
<fantasai> TabAtkins: yes, @custom-supports<br>
<fantasai> lea: or @media-condition<br>
<TabAtkins> fantasai: I like media-condition and supports-condition<br>
<lea> or @media-query and @supports-query<br>
<fantasai> astearns: Lots of feedback and enthusiasm, seems like we should work on it<br>
<fantasai> lea: Draft into next level of conditoinal?<br>
<fantasai> astearns: Add it to a new diff spec? Happy to take that resolution, or put it off if ppl wnat more details before a draft<br>
<fantasai> fantasai: seems ready for a draft<br>
<fantasai> lea: Shoudl be in the same spec as @custom-media<br>
<fantasai> fantasai: yes<br>
<lea> other naming idea: @supports-test @media-test<br>
<fantasai> RESOLVED: Draft this into the same spec as @custom-media<br>
<fantasai> RESOLVED: Add Lea as editor of that spec<br>
<TabAtkins> scribe+<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12622#issuecomment-3204959140 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 09:02:23 UTC