- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 19:15:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[mediaqueries-5][css-conditional-5][css-mixins-1] Order dependent rules and adopted stylesheets`, and agreed to the following:
* `RESOLVED: Revert earlier resolution about order-dependence, instead make @custom-media/supports and @mixins use the mechanism in this issue to resolve name collisions`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> scribe+<br>
<fantasai> TabAtkins: Last discussed in Paris last year, a lot of rules we are adding apply during early style sheet processing and can have interesting effects on style sheet processing like imports.<br>
<fantasai> TabAtkins: How do we deal with collisions in names?<br>
<fantasai> TabAtkins: We have to resolve to one of potentially multiple named declarations.<br>
<fantasai> TabAtkins: Plus, they could be inside conditional rules<br>
<fantasai> TabAtkins: and then can chain things and create cycles<br>
<fantasai> TabAtkins: In Paris, we decided that these sorts of rules have strict order dependence<br>
<fantasai> TabAtkins: They use the named rule that is the most recently defined (last) *at that point*<br>
<fantasai> TabAtkins: A rule after the reference will be ignored.<br>
<fantasai> TabAtkins: So definition of certain names can different definitions depending on where they are<br>
<fantasai> TabAtkins: This is very novel. Doesn't match how CSS works in any other sense.<br>
<fantasai> TabAtkins: It solved the problem, but now authors have to learn a new model of how things work.<br>
<fantasai> TabAtkins: Can't rely on global "last wins" rule that existing concepts use<br>
<dbaron> (this also seems weird from a mutating-CSSOM-later perspective)(<br>
<fantasai> TabAtkins: Anders has been working on a way to restore name conflict handling more closely to the "last wins" rule<br>
<fantasai> TabAtkins: The exact details are maybe too complicated to explain, but details in this issue.<br>
<emilio> q+<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<astearns> q+ emilio<br>
<fantasai> TabAtkins: You do a first pass to determine the dependencies of a rule.<br>
<fantasai> TabAtkins: Using that graph, you resolve any cycles.<br>
<fantasai> TabAtkins: Just like variables, we kill the cycle and all its definitions<br>
<fantasai> TabAtkins: Now with the set of valid definitions, figure out which is last one, and evaluate conditions properly.<br>
<fantasai> TabAtkins: The precise details are complex, but not too hard to spec.<br>
<fantasai> TabAtkins: Emilio reviewed and said while it's harder than order-dependent version, it's more reasonable<br>
<fantasai> TabAtkins: We also like it because it avoids learning a new conflict resolution rule<br>
<fantasai> TabAtkins: And also works better with shadow DOM.<br>
<fantasai> TabAtkins: More CSSy = better.<br>
<kizu> q+<br>
<fantasai> TabAtkins: If people trust Anders and Emilio, would like to undo Paris resolution and adopt this one instead.<br>
<astearns> ack emilio<br>
<fantasai> emilio: Agree it's a better model. But some drawbacks.<br>
<fantasai> emilio: Some things change behavior subtly depending on whether using a custom thing or not<br>
<TabAtkins> `@import "URL" supports(foo: bar)`<br>
<fantasai> emilio: For example, @import with supports(), if the browser doesn't support, it won't even try to load<br>
<TabAtkins> ^^^ defined to *not load* the URL if the supports() fails<br>
<fantasai> emilio: But with this setup we do need to load them, because the custom media definition might be inside the stylesheet itself.<br>
<fantasai> emilio: I don't see a good way to work around this.<br>
<fantasai> emilio: Other than scoping the names, which we didn't want to do.<br>
<fantasai> emilio: Not sure there's another user-visible change here.<br>
<TabAtkins> but if it's `@custom-media --foo (foo: bar); @import "URL" supports(--foo);`, we have to early-load it because we don't know the custom media yet<br>
<fantasai> anders: Yeah, that's the main downside. We'd have to load that import unconditionally so we can hunt for cycles in there.<br>
<TabAtkins> (Sorry, @custom-supports there)<br>
<fantasai> anders: I think the drawback there is worth it.<br>
<fantasai> emilio: Yeah, I think I agree with making that tradeoff.<br>
<fantasai> emilio: We have to do a bit more work, but the result is uncontroversially better with this proposal.<br>
<lea> q?<br>
<fantasai> anders: It doesn't change behavior. It just changes loading.<br>
<fantasai> emilio: But if you have layers and stuff?<br>
<fantasai> emilio: I guess those are conditionally defined so it's ok.<br>
<fantasai> emilio: But the loading behavior is somewhat observable.<br>
<fantasai> emilio: But in the end, not observable.<br>
<fantasai> anders: If we discover a real behavior difference here, then we should revisit.<br>
<fantasai> emilio: Maybe test unconditionally loading all @imports and see if there's a change.<br>
<astearns> ack kizu<br>
<fantasai> kizu: Will later mixin win for all @apply, or will you define a mixin and the use it and then define another mixin with the same name and use that?<br>
<fantasai> TabAtkins: You will always use the last declared name<br>
<fantasai> kizu: This is a huge change for mixins. And big issue for library authors if we don't have any lexical scoping.<br>
<fantasai> kizu: When operating on DOM things, we have specificity, etc. to scope things in the tree.<br>
<fantasai> kizu: But mixins and functions have no scoping.<br>
<fantasai> kizu: In CSS, we already have this problem with @keyframes etc.<br>
<fantasai> kizu: But for mixins and functions, we need a way to lexically scope things if we do this<br>
<emilio> q+<br>
<fantasai> kizu: Because otherwise if I use a --foo function, and someone else defines a --foo function, my code will break.<br>
<fantasai> TabAtkins: @function isn't affected by this, it takes the last definition always anyway.<br>
<fantasai> TabAtkins: This makes @mixin work the same way as @function.<br>
<fantasai> TabAtkins: You *can* use layers. You can make sure you're layering.<br>
<fantasai> fantasai: But then you have the opposite problem which is your stuff breaks their stuff.<br>
<fantasai> TabAtkins: All of our name-defining at-rules have the same problem. So they should have the same solution.<br>
<astearns> ack dbaron<br>
<andruud3> q+<br>
<fantasai> dbaron: I haven't dug into details, but want to make the general point that performance characteristics are behavior.<br>
<fantasai> dbaron: Even if what rules match and values of properties are don't change, performance characteristics do matter to developers and users.<br>
<fantasai> dbaron: Maybe it's the right tradeoff, but I don't think we should say "oh we're not changing behavior" here.<br>
<fantasai> dbaron: If you can sacrifice something else to get that performance back, might want to do that.<br>
<romain> Authors can make this tradeoff themselves. They can not use a custom supports<br>
<fantasai> TabAtkins: Problem is it's a cycle detection issue. We need to know what's inside the custom supports query.<br>
<romain> And use a regular supports query instead<br>
<fantasai> TabAtkins: We will retain the loading behavior, aka not loading, if you don't use custom supports queries.<br>
<emilio> fantasai: I think I agree with dbaron that right now people assume if I use supports on an @import we assume it isn't loading<br>
<lea> +1 fantasai<br>
<emilio> ... and not doing a conditional loading themselves<br>
<emilio> ... I don't think the fact I'm using an aliasing mechanism...<br>
<emilio> ... people are not going to realize that perf characteristics change<br>
<emilio> ... I think that maybe we could make these things not work outside the @improt<br>
<emilio> ... @import<br>
<emilio> q+<br>
<fantasai> s/maybe we could/it would be better to/<br>
<emilio> ... +1 to kizu's concerns about scoping<br>
<dbaron> was fantasai's "these things" specifically about custom supports?<br>
<astearns> ack emilio<br>
<fantasai> yeah<br>
<astearns> ack fantasai<br>
<fantasai> emilio: Not being able to use custom supports queries outside of @import, it makes it's inconsistent.<br>
<kizu> (Linking the scoping/namespacing issue: https://github.com/w3c/csswg-drafts/issues/11798)<br>
<fantasai> TabAtkins: Link with supports also wouldn't load<br>
<fantasai> emilio: If the @import was not conditional on supports.<br>
<TabAtkins> emilio: if the @import wasn't conditional, it should definitely let you define custom-media/etc outside of the import. common design system thing<br>
<fantasai> emilio: Unconditional @import is a strong use case. If you have @import "design-system-thing-defining-breakpoints"; should work outside the @import<br>
<fantasai> emilio: Making the conditional support query ...<br>
<fantasai> emilio: If you scope the names to the @import based on whether ...<br>
<bramus> scribe+<br>
<lea> q?<br>
<bramus> fantasai: if you define a named supports query inside a imported style sheet and then use that named query to condition the loading of the stylesheet<br>
<lea> q+<br>
<bramus> TabAtkins: you woul dnormallly condition another stylesheet - otherwise its cyclic<br>
<bramus> fantasai: wha tdo we do now?<br>
<bramus> emilio: now it doesnt exist<br>
<bramus> … with the paris behavior, if the condition was not defined, it doesnt match and you dont load the import<br>
<bramus> … but it has the other weird thing if then somebody overwrites the condition later on, it doesnt work<br>
<bramus> … and so with the behavior that andruud is proposing you need to go inside the import to catch cycles<br>
<bramus> … if you conditionally define something inside the import <missed> you need to catch that<br>
<bramus> … as it may affect the conditition on the import<br>
<bramus> … dont see way to prevent that wihtout scoping them to the stylesheet, but that might be bad<br>
<bramus> … because a condition might then no longer work<br>
<romain> q+<br>
<bramus> … the loading is the least bad of the option<br>
<romain> q-<br>
<fantasai> bramus: can we disallow using custom supports to condition an @import?<br>
<bramus> TabAtkins: <missed><br>
<bramus> emilio: disallowing cistom supports inside supports() would be unfortunate<br>
<bramus> TabAtkins: it would be wrid to disallow this because the loading characteristics arent ideal<br>
<bramus> fantasai: when they are not true<br>
<bramus> emilio: <missed><br>
<bramus> fantasai: most of the time you expect them to be false some of the time at least<br>
<bramus> … it is increasingly true that they are not false<br>
<bramus> … lots of code that might be ???<br>
<bramus> emilio: or like negated supports condition<br>
<bramus> fantasai: to load fallback styles<br>
<bramus> TabAtkins: and this will behavior will make tha twork correctly<br>
<bramus> … but means that if you dont need to get that content to load, youd still get network traffic<br>
<bramus> fantasai: how does that interact with script?<br>
<bramus> TabAtkins: JS libs dont have this sort of condition<br>
<bramus> … you can execute a supports query in JS, bu twill be state of the thing at the time<br>
<astearns> ack andruud<br>
<romain> q+<br>
<bramus> andruud: to respond to kizu. you have a better proposal for lexical scoping. order depending is poor substitute for it<br>
<bramus> … only applies to few select ???, but you want a more generic thing<br>
<bramus> … dont think its workth about thinking order dependence … ahve a much better proposal from you to consider<br>
<bramus> kizu: the issue about namespacing (lexical scoping) would be nice to have it someehwere alongside functions and mixins, tha tway authors can use ??? would be greatto think about it in the same room<br>
<bramus> … small note: if we scope this to a stylesheet, well have to have some way to scope it without ??? stylesheet. when some bundler unwraps it, they need to be able to scope things inside<br>
<bramus> … we need to have it without wrapping things int eh stylesheet<br>
<astearns> ack lea<br>
<bramus> TabAtkins: agree<br>
<bramus> lea: do i understand correctly that these custom supports and media rules work in a last one wins fashion?<br>
<bramus> emilio: after this change?<br>
<bramus> lea: after<br>
<bramus> TabAtkins: last valid one wins<br>
<bramus> … or most poweful one (layers)<br>
<bramus> lea: and these can be parsed before import, right?<br>
<bramus> … could they come before @import?<br>
<bramus> TabAtkins: yes, tha tis the intention<br>
<lea> scribe+<br>
<romain> that is more syntactic sugar, doesn't really change anything else, right?<br>
<TabAtkins> yes, that's sugar<br>
<lea> lea: If we are willing to relax parsing, do we even need a dedicated `supports()`, syntax, can't we just next the `@import` inside a regular `@supports {}` rule which also gives us more flexibility? I believe it hasn't been implemented anywhere yet?<br>
<bramus> emilio: this is tangential ad doesnt fix the issue<br>
<bramus> lea: but reduces the API surface<br>
<bramus> emilio: increases<br>
<bramus> TabAtkins: <missed><br>
<bramus> lea: will it still be true that @import starts loading before ??? is parsed?<br>
<fantasai> https://caniuse.com/mdn-css_at-rules_import_supports<br>
<astearns> s/???/the stylesheet/<br>
<lea> lea: is the entire stylesheet going to be parsed before `@import` starts loading?<br>
<bramus> TabAtkins: if you make an @import condtioan on custom supports, will have same behavior as making it depending on MQ<br>
<astearns> q?<br>
<lea> lea: Because otherwise a later rule can override it<br>
<bramus> … only change is you have a suppports condition that is not custom: we evaluate immedaiately and might skip load entirely<br>
<bramus> lea: and then issue is what happens if you load a stylesheet tha toverrides the custom supports condition<br>
<lea> lea: so the issue is cycles when you load a stylesheet that cancels its own loading?<br>
<bramus> TabAtkins: then its cyclic<br>
<bramus> … if it was true and then false, then …<br>
<bramus> emilio: no, not inside<br>
<bramus> … afterwards<br>
<bramus> lea: both<br>
<bramus> TabAtkins: we have to undocntiaily load, but might not apply<br>
<bramus> lea: (thinks)<br>
<bramus> … what are proposed solutions? load and ignore?<br>
<lea> lea: so implementation aside, conceptually what is the right solution? It is applied or not?<br>
<bramus> TabAtkins: already have disallows custom supports on @import entirely or chang ebheabior ntirely to lexcailly scope them, or change the loading behavior (as prposed here)<br>
<bramus> emilio: another proposal could be to always do th eload, even if the support fails<br>
<bramus> TabAtkins: seems worse<br>
<bramus> emilio: for completeness, would be consistent<br>
<bramus> TabAtkins: that fails david’s loading behavior is important stance<br>
<bramus> lea: need to think about this more<br>
<astearns> ack romain<br>
<bramus> romain: this proposal is a lot better than what is originally in the spec<br>
<bramus> … need to make a tradeoff in some cases<br>
<bramus> … also wonder how many authors will use custom queries in @import rules<br>
<dbaron> agree that the new proposal is better<br>
<fantasai> +1 romain<br>
<bramus> … custom queries will be popular in style rules, but in import rules … would be fine with disallowing entirely<br>
<bramus> +1<br>
<bramus> emilio: custom supports can kinda buy, but custom media …<br>
<bramus> … you are suggesting to disallow custom supports<br>
<bramus> … if it suddenly didnt work …<br>
<bramus> romain: easier to explain and discover than th eloading behavior for authors<br>
<bramus> emilio: not sure<br>
<bramus> … feels like adding a fallback for old browser and never test so would remain broken<br>
<bramus> TabAtkins: very vali<br>
<bramus> … if you are loading a polyfill<br>
<bramus> … you wont test<br>
<bramus> … alright to have that page be slower<br>
<bramus> emilio: might berak modern browsers as well<br>
<bramus> TabAtkins: that is the tradeoff: all browsers or only older browsers<br>
<bramus> romain: but authors can still optoimize<br>
<bramus> fantasai: I think we need to put this in an advisement box in the spec. LIke “if you try to use on @import it wont block loading”<br>
<lea> q+<br>
<bramus> TabAtkins: put it there and in the @import definition<br>
<bramus> fantasai: yes<br>
<astearns> ack lea<br>
<bramus> lea: wether it loads (http request) and apply is sepaarte thing<br>
<bramus> … if we allow custom supports and they are never true, there is no reason to kick off loading<br>
<bramus> … if it becomes false later then we can unapply<br>
<bramus> TabAtkins: we could ??? and then preserve dont load as it fails the supports query<br>
<bramus> … other is always load, but only apply when it needs to<br>
<bramus> lea: feels like penalzing older browsers<br>
<bramus> … could be may beas “if this every becomes true then fetch it”<br>
<bramus> TabAtkins: we dont have a sort of pending load right now<br>
<bramus> … stylesheets load immediately<br>
<bramus> emilio: not really. reason to undocntoiaally load MQ gated ones is FOUC<br>
<bramus> … with supports() you know you are never applying<br>
<emilio> The interesting case would be: `@supports "table-layout.css" not supports(display: grid);` vs `@supports "table-layout.css" not supports((--grid-layout));`<br>
<bramus> TabAtkins: if you conditionally load, and then it becomes true, you’ll have to wait on the network<br>
<bramus> lea: seems like an acceptable tradeoff<br>
<bramus> TabAtkins: that is what we made with print media stylesheets always loading<br>
<bramus> … because when you do print, we dont want to wait on the network<br>
<bramus> lea: that is different ; user activitiy … can press print at any point<br>
<bramus> … the @supports usually dont hcnage<br>
<bramus> TabAtkins: but when they do, other stuff might depend on it<br>
<bramus> lea: reallisticly the ar enot equivalent<br>
<bramus> emilio: you could have a stylesheet load slower<br>
<bramus> astearns: not gonna get to that today … can take a resolutoin fo r??? and leave open how we adapt how import behaves given that we are removing the order dependence<br>
<bramus> TabAtkins: mixins, custom media, custom suupport … and potentially future things<br>
<bramus> lea: could someone outline the proposed resolution?<br>
<bramus> TabAtkins: there is no longer is an order dependence<br>
<bramus> … last one defined a true condition wins<br>
<bramus> astearns: and we are in agreement that that is better<br>
<TabAtkins> proposed resolution: Revert earlier resolution about order-dependence, instead make @custom-media/supports and @mixins use the mechanism in this issue to resolve name collisions<br>
<bramus> emilio: so we area ccepting the proposal<br>
<bramus> andruud: and then details about support-affected details TBD<br>
<TabAtkins> TBD @import supports() with a custom supports<br>
<bramus> astearns: objections?<br>
<bramus> RESOLVED: Revert earlier resolution about order-dependence, instead make @custom-media/supports and @mixins use the mechanism in this issue to resolve name collisions<br>
<dholbert> scribenick: dholbert<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13041#issuecomment-3819756713 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 19:15:23 UTC