- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 15:28:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[selectors][css-conditional] Pseudo-class or combinator that is syntactic sugar for wrapping in an `@rule` ``, and agreed to the following: * `ACTION: Lea to open issue with these use cases and ideas tagged mixins` * `RESOLVED: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> lea: a while back i posted a proposal for :media() pseudo-class<br> <TabAtkins> lea: was well received, tho didn't get finished<br> <TabAtkins> lea: since then i've been spotting a more general problem, not just MQs<br> <TabAtkins> lea: combining filterering logic from other at-ruels with selectors<br> <TabAtkins> lea: conditional rules in general are obvious example<br> <astearns> (we just added media() to @import: https://github.com/w3c/csswg-drafts/issues/10972#issuecomment-2773298233)<br> <TabAtkins> lea: but also @layer. use-case is you want to style regular elements by tag name, but give them lower priority by defualt, or offer a class name to apply them as well<br> <TabAtkins> lea: or @scope, with one selector in the scope and another selector outside<br> <TabAtkins> lea: @starting-style too, might want it to share some styles with a regular selector<br> <TabAtkins> lea: so at this point I think we need a more general solution<br> <TabAtkins> lea: i posted a proposal but am not married to it, just want to solve the problem<br> <TabAtkins> lea: proposal is a pseudo-class that is generic enough, letting people specify any at-rule<br> <TabAtkins> lea: it's sugar for nesting<br> <TabAtkins> lea: in every example i gave, the "after" version includes duplicates<br> <TabAtkins> lea: someone thought this was a compact way to do nesting; that's a benefit, sure, but not the point<br> <TabAtkins> lea: right now if you have something applied via an at-rule and a selctor, duplication is all you can do. and someontimes that can be *dozens* of declarations<br> <TabAtkins> lea: Oriol suggested it only makes sense for CSSGroupingRule<br> <TabAtkins> lea: that drops @page, but that's not a major use-case<br> <kizu> q+<br> <TabAtkins> lea: someone suggested the opposite, having an at-rule that allows combining with selector logic<br> <oriol> q+<br> <TabAtkins> lea: that could work, but it's less flexible, selectors are better known<br> <TabAtkins> TabAtkins: you also ccan't combine multiple at-rules that way<br> <astearns> ack kizu<br> <TabAtkins> kizu: i think it would be great to have something like that. the problem is quite common, for darkmode for example<br> <TabAtkins> kizu: have a selector that applies it, and an at-rule that applies it by default<br> <TabAtkins> kizu: this could potentially be done with block-level mixins, but it woudln't be a sconvenient as what's expressed in this issue for one-offs<br> <lea> Dark mode is actually a good use case for combining the logic with `@scope`, if you have e.g. `.dark` and `.light` and `.invert` classes<br> <emilio> q+<br> <TabAtkins> kizu: you could make a mixin that wraps any number of rules and use it in multiple spots<br> <TabAtkins> kizu: but for one-offs, having this just live in the selector is convenient<br> <astearns> ack oriol<br> <TabAtkins> oriol: mentioning a point i raise din the issue<br> <TabAtkins> oriol: this is equivalent to some desugaring, and we have options<br> <fantasai> I have to drop soon, but I have some concerns about using a pseudo-class here.<br> <TabAtkins> oriol: expand to the desugar, or say the behavior is equivalent<br> <lea> q?<br> <lea> q+<br> <TabAtkins> oriol: my concern with the first is it's easy to have combinatorial explosions<br> <TabAtkins> oriol: with second option it seems more complex to implement<br> <TabAtkins> oriol: so a bit tricky<br> <fantasai> Because a pseudo-class is classifying an element, and these conditions aren't connected to an element but to a selector as a whole<br> <TabAtkins> oriol: since the order of these things matter, i don't think a pseudo-class is right<br> <TabAtkins> oriol: should be a combinator maybe, use the @ as a combinator<br> <lea> qq+<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to oriol<br> <TabAtkins> lea: right, i forgot about the combinator idea, i do like that better. Tab will have to commont on whether it's possible grammar-wise<br> <TabAtkins> TabAtkins: i'll have to think about it<br> <astearns> ack emilio<br> <TabAtkins> emilio: i'm curious about the ocmbinator idea. what does it combine with?<br> <TabAtkins> emilio: at least for some of these reules it's quite complicated. @media and @supprots are fine, but @laer and @scope change the cascade order<br> <TabAtkins> emilio: i'm just not sure how we'd define mixing multiple of these<br> <TabAtkins> emilio: for each rule that provides a boolean answer, that's fine. for @scope and @container, it might make sense as long as we prevent the cascade-order side effects, otherwise i don't know how it works. how does multiple @scope work<br> <TabAtkins> emilio: so i'd rather not start making selectors affect the cascade order other than via specificity<br> <lea> q?<br> <astearns> ack dbaron<br> <ntim> Not super convinced about the cost/benefit ratio of the idea<br> <TabAtkins> dbaron: another concern is if we want to do this, we shoudl figure out the perf characteristic we want<br> <TabAtkins> dbaron: some filtering at-rules have an expectation that the filter happens at a particiular stage. when thye look like selectors, the normal expectation for selector matching is a different stage of the process; might happen later and many more times than as an at-rule<br> <TabAtkins> dbaron: and that's tied into the question of how they're represented in the cssom, and if this expands the way oriol said<br> <TabAtkins> q+<br> <astearns> ack lea<br> <TabAtkins> lea: to emilio, @scope/layer/container ar emajor use-cases.<br> <TabAtkins> lea: just solving for conditionals would be useful, but it doesn't reach the 80% case<br> <TabAtkins> lea: @container is biggest from the non-conditional cases, then @scope then @layer<br> <TabAtkins> lea: to dbaron, i think perf should be similar to the desugared veresion or better, since we're not duplciating declarations<br> <TabAtkins> lea: to oriol, combinatorial is less here than regular nesting, less at-rules to combine with<br> <emilio> q+<br> <TabAtkins> lea: so even if we go that way, it's not as bad, and we cna introduce a maximum limit<br> <TabAtkins> lea: i think the number of at-rules in actual use is fine, two or three<br> <TabAtkins> lea: thinking more abou tthe combinator idea, while i like the syntax, i don't like that it muddles what a combinator is<br> <TabAtkins> lea: combinators get you from one element to another element<br> <TabAtkins> lea: here we're not doing that, at-rule can be wrapping the whole thing, or something at the end, etc<br> <TabAtkins> lea: not sure about this<br> <TabAtkins> lea: another benefit of doing this in selector land, selectors have forgiving handling for selectors we don't understand in :is()/:where()<br> <TabAtkins> lea: so authors could use this immediately and wrap in an :is()<br> <TabAtkins> lea: while an at-rule that's misunderstood gets dropped entirely<br> <TabAtkins> lea: last, i was thinking what if instead of a pseudoclass, could we @sheet andd import that internally?<br> <TabAtkins> lea: could have the style rule and at-rule, then just import the @sheet inside of each<br> <TabAtkins> lea: tim, you said not sure about cost-benefit. is it the cost of the syntax or the benefit of the results?<br> <TabAtkins> ntim: cost of the syntax, mostly, and having devs understand the syntax<br> <TabAtkins> ntim: i'm not convinced the current proposals are easy to understand<br> <TabAtkins> ntim: so those combined vs the benefit from it...<br> <TabAtkins> lea: fair. i htink if the syntax was as close to the at-rule as possible would help. but there might be value in two separate resolutions<br> <TabAtkins> lea: (a) is this a problem to solve in some way, and (b) the specific syntax<br> <TabAtkins> ntim: also, where the combinator/pseudo-class fits in the order...<br> <TabAtkins> lea: that's explained in the proposal<br> <TabAtkins> lea: the pseudo-class downside is the relative order of pseudo-classes mattered, which is new<br> <lea> scribe+<br> <lea> TabAtkins: This is a problem worth solving. I had to do this duplication before, avoided doing somethings because of the duplication. I think the right place to solve it is on the declaration, neither the @rules or the selectors.<br> <lea> Combining our existing rules because they work in many ways is not super feasible in an understandable way. Giving us a mechanism to easily dedupe chunks of declarations would be good. Mixins are the obvious way, or your idea of being able to reference an `@sheet`<br> <kbabbitt> q+ to comment on the @sheet approach<br> <lea> TabAtkins: It requires more work for one-off cases, but I think that's still justified for the overall improvement. Some way to do rule-level deduplication of contents<br> <astearns> ack TabAtkins<br> <TabAtkins> dbaron: i probably agree witih Tab<br> <lea> q+<br> <emilio> q-<br> <TabAtkins> dbaron: i think there are widely different solutions to the underlying problems<br> <TabAtkins> dbaron: i'm very worried about the complexity of this particular set of solutions<br> <TabAtkins> dbaron: two things. first is comment about perf<br> <TabAtkins> dbaron: lea said shoudl be faster because less duplication<br> <TabAtkins> dbaron: what i meant was, if you have @media or @support that doesn't match, those rules get thrown out earlier than doing selector matching<br> <emilio> +1 to dbaron<br> <emilio> (Was on the queue for that)<br> <TabAtkins> dbaron: whereas if it looks like as elector, the syntax is saying "we'll try to match all of these", then we get to the top and see the :media(). we've spent all this time on selecto rmatching for rules that we could ahve avoided<br> <TabAtkins> lea: doesn't that depend on how it's implemented?<br> <oriol> This is my combinatorial explosion concern https://www.irccloud.com/pastebin/3PIUwxZd/<br> <TabAtkins> dbaron: yes, but if you assume it's going to be implemented by desugaring to some other syntax, you need to make sure that's practical to<br> <TabAtkins> dbaron: so i don't think it's trivial to say "it'll be faster", you'd need a practical proposal for the underlying model<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: and ahve a plan for what to do about it<br> <TabAtkins> dbaron: second point, when you say "is it worth solving", i think we still need to udnerstand what cost<br> <ntim> +1 to dbaron<br> <TabAtkins> dbaron: when i look at this proposal, i ask how much complexity is this adding to selector matching. is it 20% more complex, or twice as complicated?<br> <lea> q+<br> <TabAtkins> dbaron: i dont' know the answer off the top of my head, but I think when i look at a proposal like this, we're really asking the question "is it worth potentially doubling the complexity of selector matching to solve this", which i think is a real possibility<br> <TabAtkins> dbaron: while I think Tab's mixin idea is much lower cost and does get the bulk of the use-cases<br> <astearns> ack kbabbitt<br> <Zakim> kbabbitt, you wanted to comment on the @sheet approach<br> <TabAtkins> kbabbitt: wrt @sheet approach, we're very limited now in where we can put @import to reference the sheet<br> <TabAtkins> kbabbitt: apart from that, i tend to agree with tab adn david that i worry about the complexity this is adding<br> <TabAtkins> kbabbitt: i think it's worth exploring if we can solve this with mixins<br> <astearns> ack lea<br> <TabAtkins> lea: i agree with Tab as well. like I said in the beginning, i just want to solve the problem, not married to a solution<br> <TabAtkins> lea: since i've seen a lot of use-cases, their characteristics is usually you don't have a ton of them, but th eones you have are big. wrapping an entire stylesheet, an entire theme<br> <TabAtkins> lea: and you just want to wrap the whole thing with a selector *and* an at-rule<br> <TabAtkins> lea: btw to dbaron, i said we *might* gain some perf from deduplication. unsure if it's a net positive or not.<br> <TabAtkins> lea: but i might be convinced this can be done with mixins<br> <TabAtkins> lea: so, if mixins are solving this, does it chagne the cost-benefit to drop some cases? like dropping @layer and only doing conditionals or @scope<br> <astearns> q+<br> <TabAtkins> lea: is there a subset that we could carve out that makes it easier to solve with a pseudo-class?<br> <lea> `:if()` even<br> <TabAtkins> TabAtkins: [i wasn't minuted]<br> <TabAtkins> lea: smaller places come out of here, like @supports<br> <dbaron> (though on second thought, earlier filtering probably looks a bit like the bloom filter optimizations that we already have so it's probably not too hard)<br> <TabAtkins> lea: some new CQs like :stuck<br> <dbaron> (but many of the other issues remain)<br> <kizu> q+<br> <astearns> (unminuted back and forth)<br> <TabAtkins> astearns: i know mixins are still vague, but are there problems outlined in this issue that they're not a solution for?<br> <astearns> ack astearns<br> <lea> scribe+<br> <lea> TabAtkins: Mixins should be able to trivially address anything that can be nested in a style rule today<br> <lea> TabAtkins: Any model we're thinking for mixins allows that. Conditionals work, scope works, container works. layer currently doesn't, but should be fine to amend it to do so<br> <lea> TabAtkins: I think those are all the rule examples that have been given, so it should be fine<br> <lea> q+<br> <TabAtkins> astearns: so everything in this issue should be input ot our mixins work<br> <lea> TabAtkins: Yes, nested @layer is the only new use case<br> <astearns> ack kizu<br> <TabAtkins> kizu: to answer lea's q about if there's anything form what we were talkinga bout that would b euseful in a selector space, i can only really think of CQs<br> <TabAtkins> kizu: with CQs you can have a named container, then choose a container for which you're running the query<br> <TabAtkins> kizu: with selectors it could be useful as a shortcut to be able to indicate at which element you're running the querys<br> <TabAtkins> kizu: right now to do this you ahve to write a seaprate selector creating a named container<br> <TabAtkins> kizu: so kinda convenient in selectors. exception is probably not usable inside a :has()<br> <astearns> ack lea<br> <TabAtkins> lea: right now, proposals around mixins have been global. that works for the big-chunk use-cases, but less for the smaller use-cases<br> <TabAtkins> lea: liek "i just want to add two delcarations if this is supported"<br> <TabAtkins> lea: wonder if some small version of scoped mixins would be useful here<br> <TabAtkins> lea: naming things globally is hard. small targeted mixins with local names could be more lightweight<br> <lea> scribe+<br> <kizu> (https://github.com/w3c/csswg-drafts/issues/11798 — an issue about scoping named things)<br> <lea> TabAtkins: The possibilities there are interesting. Mixins will get applied before the cascade, at sheet parsing layer. We could have a notion of lexical scope, that is I think a viable thing to explore.<br> <lea> TabAtkins: No comment on whether we'll for that but it sound plausible<br> <TabAtkins> astearns: so queue is empty. close this discussion for now?<br> <TabAtkins> lea: yeah. fine to even close the issue. looks like we want to take this as input into mixins.<br> <TabAtkins> lea: so i'm hearing we're sorta in agreement about solving this as long as cost is reasonable. doing it in selector isn't reasonable in cost/complexity. so we'll take it as input to ensure mxiins satisfy these<br> <TabAtkins> TabAtkins: can I have lea open an issue on Mixins spec?<br> <TabAtkins> lea: yeah, will tag in this issue<br> <lea> ACTION: Lea to open issue with these use cases and ideas tagged mixins<br> <lea> PROPOSED RESOLUTION: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: We agree the problem needs solving, but doing it selectors seems too complex. We'll instead close this and make sure mixins satisfy these use cases.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11969#issuecomment-2776186250 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 15:28:19 UTC