- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 02:34:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2][css-conditionals] Exposing navigation/route matching`, and agreed to the following:
* `RESOLVED: Start a css-navigation ED`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> dbaron: Noam presented this twice before, in Paris and once at a Telcon since<br>
<TabAtkins> dbaron: back to use-cases<br>
<TabAtkins> dbaron: a bunch of what this is about is having styles that are conditional on the currently-active navigation, or current url<br>
<TabAtkins> dbaron: you might be navigating from URL A to B and want styles that depend on that<br>
<TabAtkins> dbaron: a bunch of the use-cases are related to VT (but this isn't VT itself)<br>
<TabAtkins> dbaron: like, if you want to set up a VT between a list and details page<br>
<TabAtkins> dbaron: so you click the item in the list, it expands to the whole page, VT shows the transition<br>
<TabAtkins> dbaron: and potentially the reverse<br>
<noamr> q+<br>
<TabAtkins> dbaron: there are other examples like a loading indicator from one thing to another specific thing<br>
<TabAtkins> dbaron: some times these depend on where you're coming from or where you're going<br>
<TabAtkins> dbaron: it's tempting to focus on the link you activated to try and do this<br>
<TabAtkins> dbaron: what we talked about before was conditional rules, conditional on where you're going to or from. we have a spec draft for that<br>
<emilio> https://wicg.github.io/declarative-partial-updates/css-route-matching<br>
<TabAtkins> dbaron: Morten has prototyped a bunch of this in chromium<br>
<TabAtkins> dbaron: not sure exactly how in sync the prototype and spec are right now<br>
<TabAtkins> dbaron: another piece we'd like to add to this is the ability to have pseudo-classes for links that are related to the nav<br>
<TabAtkins> dbaron: hopefully will have a proposal soon, been back and forth in discussion. more complicated than I thought at first<br>
<noamr> https://wicg.github.io/declarative-partial-updates/css-route-matching/<br>
<TabAtkins> dbaron: we'd previous talked about this "route map syntax" in HTML, for now we've taken it out<br>
<TabAtkins> dbaron: but fo rnow we're prototyping b y putting URLs into the css<br>
<TabAtkins> dbaron: a function represented URL patterns (based on WHATWG spec)<br>
<TabAtkins> dbaron: what I'd like to get to is getting the group to adopt the draft. there might be qs about where to put it<br>
<astearns> q+<br>
<lea> q?<br>
<astearns> ack noamr<br>
<TabAtkins> noamr: wanted to quote something from a VT user<br>
<TabAtkins> noamr: "trying to replace the default cross-fade with directional animations, doing without JS right now is like driving without turn signals"<br>
<TabAtkins> noamr: today a lot of people are just cross fading, or otherwise not doing something that gives orietnation<br>
<TabAtkins> noamr: because they'd need JS to actually do it<br>
<fantasai> Maybe less "driving without turn signals" and more "driving without a steering wheel"...<br>
<lea> q+<br>
<JakeA> q+<br>
<TabAtkins> noamr: we didn't want to discuss all the open issues here, just want to check that this is a valid use-case and we're going in the right direction<br>
<TabAtkins> noamr: to adopt the draft as ED and continue form there<br>
<TabAtkins> astearns: 1, why isn't the JS solution sufficient?<br>
<TabAtkins> noamr: two reasons. first, this is a styling decision. CSS VT is a styling feature.<br>
<TabAtkins> noamr: second, perf wise, we're trying to avoid event-driven JS when we can, especially in perf-sensitive places like first paint after navigation<br>
<kbabbitt> qq+ to comment further on JS<br>
<TabAtkins> noamr: using JS, now we have to run script before we can show anything. if we can set it tup in advance in CSS, no need for that<br>
<TabAtkins> noamr: it's also just kinda hard<br>
<astearns> ack astearns<br>
<TabAtkins> astearns: I just wonder if we want to wait on more author patterns<br>
<TabAtkins> noamr: we've already done that, VTs have been out for two years. this *is* the author feedback about the lack.<br>
<TabAtkins> astearns: my other q was about URL patterns, but your draft answers that<br>
<astearns> ack kbabbitt<br>
<Zakim> kbabbitt, you wanted to react to noamr to comment further on JS<br>
<wendyreid> q+<br>
<TabAtkins> kbabbitt: about JS, less that JS isn't sufficient, it's that the more we can move into the engine the better<br>
<TabAtkins> kbabbitt: some of our perf teams are trying to rip out as much JS as possible<br>
<astearns> ack lea<br>
<TabAtkins> lea: I think this is a problem worth solving, authors always talk about how hard routing is<br>
<TabAtkins> lea: could imagine conditionals in HTML based on the route, use-cases in JS based on the route, etc<br>
<TabAtkins> lea: tho it seems you don't want the indirection of naming your route. simple cases you just want to match a single route. then complex cases with lots of routes that you want to use names<br>
<astearns> q+<br>
<TabAtkins> lea: so it seems useful to have both, names and anonymous<br>
<noamr> q+<br>
<TabAtkins> lea: since there are use-cases for both, and naming global routes needs coord across the platform, might be useful to do anonymous matching in CSS and then solve route-naming on top<br>
<TabAtkins> lea: also, someone mentioned @document before, would be interesting to see lessons<br>
<astearns> ack JakeA<br>
<TabAtkins> JakeA: @document would have predated URLPattern<br>
<JakeA> qq+ I didn't get to my comment<br>
<TabAtkins> emilio: it's not particularly complicated to implement, matching a URL can be expensive, but...<br>
<JakeA> qq+<br>
<TabAtkins> emilio: I think it just never got enough adoption<br>
<JakeA> (I didn't get to my comment)<br>
<TabAtkins> emilio: I removed it because it was causing some compat pain<br>
<TabAtkins> emilio: we still support @moz-document with an empty URL, it detects Gecko<br>
<TabAtkins> dbaron: the original motivation was for user stylesheets<br>
<astearns> q-<br>
<TabAtkins> lea: URLPattern in JS has the nice feature where you can extract features form the URL. down the line, might be useful to think about designing to match parameters and use them<br>
<TabAtkins> lea: could solve other problems, like SVG Params spec<br>
<TabAtkins> dbaron: we were actually looking at using URL patterns Params for the pseudo-classes. part of the complicated thing is exactly what to do there, there's multiple things to match between, hard to make ergonomic in CSS.<br>
<lea> s/you can extract features form the URL/you can extract params form the URL/<br>
<TabAtkins> dbaron: part of the reason this isn't ready yet is because I want to figure out the param stuff<br>
<TabAtkins> dbaron: also doing patterns now and route maps later is already what we're thinking<br>
<TabAtkins> JakeA: general support<br>
<astearns> +1 to separating urlpattern()<br>
<TabAtkins> JakeA: perf, relative to a navigation probably not a huge issue to run a little JS<br>
<TabAtkins> JakeA: but wrt back/forward navs, if the Vt has any directionality you want to change if it's a back navigation<br>
<TabAtkins> JakeA: so yes, important to have that doable at a high level<br>
<astearns> ack JakeA<br>
<Zakim> JakeA, you wanted to react to JakeA<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about integration with navigation<br>
<TabAtkins> fantasai: I think the draft could use some examples, took a while to figure out what was happening<br>
<TabAtkins> fantasai: I think overall this looks like a reasonable design for the idea<br>
<emilio> q+<br>
<TabAtkins> fantasai: one thing that through me off was the at-rule being @route, it doesn't declare a route it declares a condition based on the current navigation state of the doc<br>
<TabAtkins> fantasai: so my suggestion is to use @navigation instead, and use @route in the future as the named routing feature<br>
<lea> q?<br>
<TabAtkins> fantasai: that would also let you have :route() pseudo matching up<br>
<TabAtkins> fantasai: once I figured out that term confusion it made a lot more sense<br>
<TabAtkins> JakeA: how would that be different from @document if it supported URLPattern?<br>
<emilio> q-<br>
<TabAtkins> fantasai: @document is the current doc, right? but this condition might be the current doc or the active nav<br>
<TabAtkins> JakeA: I meant about @route<br>
<lea> this is a bit like masonry: route is the term of art, but to those not yet inducted into all this it seems very confusing. I still remember how confused I was when I first heard about routes.<br>
<TabAtkins> fantasai: that's for declaring a named route<br>
<TabAtkins> fantasai: can later do @navigation route(foo) {...}<br>
<astearns> route also sounds like root (depending on the speaker)<br>
<TabAtkins> fantasai: [goes over her :route example again]<br>
<lea> `@navigation` sounds like it's about going somewhere, rather than about where you _are_<br>
<lea> q+<br>
<fantasai> It's about the current state of navigation<br>
<fantasai> So yeah, it *is* about going somewhere<br>
<TabAtkins> wendyreid: this also means we can do reduced-motion response, people can turn them off easily if they're in CSS<br>
<TabAtkins> fantasai: that would turn off on the VT side, you can already do that<br>
<astearns> ack wendyreid<br>
<adamargyle> can the common case of back navigation being a reverse of the prior view transition, be a single easy opt in instead of needing to intercept or @route declare the intent which plays keyframes in reverse? seems like something like this could work:<br>
<adamargyle> @view-transition {<br>
<adamargyle> navigation: auto;<br>
<adamargyle> backwards: reverse;<br>
<adamargyle> }<br>
<astearns> ack noamr<br>
<astearns> ack lea<br>
<TabAtkins> noamr: I think we had this discussion internally about naming. "route" was a bit of a relic, coming from the HTML history. so this reflects our internal convo<br>
<TabAtkins> lea: echoing from IRC, agree with changing "route". "route" is a term of art, but people not already familiar with it find it weird/confusing<br>
<TabAtkins> lea: I was very confused when I first started learning about this<br>
<TabAtkins> lea: but I also find navigation a bit confusing, sounds like it's about going somewhere or coming from somewhere<br>
<JakeA> q+<br>
<TabAtkins> lea: rather than where you currently are<br>
<Jxck> route mapping json seems quite similar w/ speculation rules.<br>
<Jxck> https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API<br>
<noamr> q+<br>
<TabAtkins> lea: Elika said it *is* about coming from somewhere, but I thought this was most about where you are<br>
<TabAtkins> dbaron: the current proposal has both<br>
<astearns> ack Jxck<br>
<TabAtkins> dbaron: the thing we're probably focused on more is the "where are you going", not "where you are", but it can do both<br>
<astearns> ack JakeA<br>
<TabAtkins> JakeA: these rules apply during same-doc navigations too, right/<br>
<TabAtkins> noamr: yes<br>
<TabAtkins> lea: and the rule can be used for other things than VT<br>
<astearns> ack noamr<br>
<TabAtkins> noamr: scoping back to what do we need to do to get this into an ED<br>
<TabAtkins> noamr: we're not trying to figure out these issues today<br>
<astearns> ack fantasai<br>
<TabAtkins> JakeA: examples<br>
<TabAtkins> fantasai: yes<br>
<TabAtkins> fantasai: add examples, put in ED<br>
<kbabbitt> +1 fantasai<br>
<fantasai> @navigation (at: urlpattern) {<br>
<fantasai> styles that apply to a page at urlpattern<br>
<fantasai> }<br>
<fantasai> @navigation (from: urlpattern1) and (to: urlpattern2) {<br>
<fantasai> styles that apply when you are navigating from urlpattern1 to urlpattern2<br>
<fantasai> }<br>
<fantasai> @navigation (route: --foo) {<br>
<fantasai> styles that apply when navigation state is --foo<br>
<fantasai> }<br>
<JakeA> q+<br>
<fantasai> @route --foo {<br>
<fantasai> from: urlpattern3;<br>
<fantasai> to: urlpattern4;<br>
<fantasai> }<br>
<fantasai> a:route(--foo) {<br>
<fantasai> styles for link that go from urlpattern3 to urlpattern4<br>
<fantasai> }<br>
<fantasai> a:route-to(urlpattern) {<br>
<fantasai> styles for link that go to urlpattern<br>
<fantasai> }<br>
<TabAtkins> JakeA: what's the lifetime of the @navigation rule? especially with a from()<br>
<astearns> ack JakeA<br>
<TabAtkins> noamr: directly tied to Navigation API concepts<br>
<TabAtkins> noamr: navigation.transition have "from" and "to", it's tied to that<br>
<TabAtkins> JakeA: that doesn't work for cross-document<br>
<TabAtkins> noamr: I have a proposal to fix that<br>
<TabAtkins> noamr: the "from" and "to" starts at the navigate event, "to" changes at redirect and swap<br>
<TabAtkins> noamr: and in the next document, the "to" is only until the first frame<br>
<TabAtkins> JakeA: makes sense<br>
<TabAtkins> noamr: first frame + view transition<br>
<TabAtkins> astearns: so details like that in the draft, examples<br>
<TabAtkins> noamr: so suggesting css-navigation for the ED name<br>
<TabAtkins> astearns: any objections to doing an ED yet?<br>
<JakeA> q+<br>
<TabAtkins> astearns: proposed to start an ED for css-navigation<br>
<TabAtkins> JakeA: I think most important part of this is back vs forward, that's not part of this yet, right?<br>
<TabAtkins> noamr: not at the moment<br>
<TabAtkins> JakeA: okay I think it should be<br>
<TabAtkins> JakeA: [summarizes what he meant again]<br>
<TabAtkins> RESOLVED: Start a css-navigation ED<br>
<JakeA> dbaron: https://simple-vt-demos.jakearchibald.com/directional-transition/ - this transition moves differently if you use the back button. I think this is a really common case<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12594#issuecomment-3530564088 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 02:34:39 UTC