- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 11:49:44 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Exposing navigation/route matching`.
<details><summary>The full IRC log of that discussion</summary>
<ydaniv> noamr: presenting route matching, something new, more informative<br>
<ydaniv> ... to start prototyping, get feedback and reactions to guide it<br>
<ydaniv> ... in a few months get to something resolvable<br>
<ydaniv> ... showing 5 issues quickly, that bring this issue up<br>
<ydaniv> ... starting with VTs for dialogs<br>
<ydaniv> ... we discussed before navigation matchings, between different URLs, between different pages, you want different transitions<br>
<ydaniv> ... another conversation about going from a list view into details view<br>
<ydaniv> ... a major use-case for VTs<br>
<ydaniv> ... from another side you have a desire to do things ppl do on SPAs and apps, allow more primitves to do that OOTB<br>
<ydaniv> ... more outside of CSS, allow more user-agency for these kind of transitions<br>
<ydaniv> ... try finding things that can help in these cases<br>
<ydaniv> ... a few things in that direction, the one we'll discuss today is a "route" to be a DOM primitive<br>
<ydaniv> ... to be able to declare a route as a web platform primitive, with a pattern, like a regexp superset, allow authors to give them names<br>
<ydaniv> ... and specify rules about going between them<br>
<ydaniv> ... then how they tie into CSS<br>
<ydaniv> ... not specific to VTs<br>
<ydaniv> ... dealing with routes like they're an attribute of the DOM<br>
<emilio> q+<br>
<kbabbitt> q+<br>
<ydaniv> ... then in CSS be able to relate to named routes to specify rules inside them<br>
<astearns> q+ fantasai<br>
<ydaniv> ... then in VTs be able to specify different animations between different routes<br>
<ydaniv> ... style link in particular ways, like if its a link we came from, or navigating to<br>
<SebastianZ> q+<br>
<astearns> ack emilio<br>
<ntim> @-moz-document<br>
<ydaniv> emilio: the @route stuff, FF used to have @-moz-document to specify patterns<br>
<ydaniv> ... it feels weird to have that extra layer<br>
<ydaniv> noamr: it's a option to have path names, URLs works better in JSON<br>
<ydaniv> ... specific URL matching we tried to experiment with, URL patterns are not exactly strings<br>
<ydaniv> emilio: you can do some glob stuff, <missed><br>
<ydaniv> noamr: it's going to be exposed to scripts for matchMedia<br>
<ydaniv> ... allows basic stuff of navigation without scripting<br>
<ydaniv> ... no need to do pushState stuff<br>
<ydaniv> ... potentially other stuff in the future, but clearly not a CSS feature, just that CSS is the first use-case<br>
<ydaniv> emilio: assuming you have to make all the routes CSS-valid<br>
<astearns> ack kbabbitt<br>
<ydaniv> noamr: probably going to be in quotes<br>
<ydaniv> kbabbitt: when I saw the @route(home) was confusing, seems like from A to B<br>
<ydaniv> ... to emilio's points, author is defining states, they may want to have something called initial and it's a reserved keyword<br>
<astearns> ack fantasai<br>
<ydaniv> fantasai1: had the same confusion<br>
<emilio> q+<br>
<ydaniv> ... is it location classes, and then have routes from-to location<br>
<kbabbitt> +1 fantasai1<br>
<ydaniv> ... so mayabe have more sense to have @location<br>
<ydaniv> ... also, do we want to have JSON here? or have CSS syntax to be easier to write for most ppl<br>
<ydaniv> ... can have a canonical JSON as well for LLM<br>
<ydaniv> ,,, I think the idea to be able to name locations and reference them is very useful<br>
<kizu> q+<br>
<ydaniv> ... so you're use-cases make sense<br>
<ydaniv> ... I think emilio's point that this should be a URL pattern makes sense, ability to put in a literal <missed><br>
<emilio> `@media document-url("/foo/:bar") {` seems potentially nice?<br>
<ydaniv> noamr: a route is usually a path connected with rules<br>
<ydaniv> ... all things that exist today are used with the name route<br>
<ydaniv> ... the JSON stuff is also trying very hard to not be noval<br>
<ydaniv> ... it's taken from import maps, currently common, follows that script, doesn't feel like a CSS feature<br>
<ydaniv> fantasai1: I think CSS syntax is reasonable<br>
<ydaniv> noamr: it's a good option, open question<br>
<ydaniv> fantasai1: there was previously an XML syntax, very verbose, very complex, very generic<br>
<ydaniv> ... JSON is a very generic syntax like XML, it's necessary, but CSS has more sophisticated syntax that allows to do more, be more readable<br>
<fantasai1> s/very complex//<br>
<ydaniv> noamr: open to discussion. Having inline URLs inside CSS is things we can consider<br>
<astearns> ack SebastianZ<br>
<fantasai1> s/XML syntax/XML schema language, RelaxNG, which had an XML-based syntax that was/<br>
<ydaniv> SebastianZ: I think it's reasoable to split from CSS<br>
<ydaniv> ... and can be reused in both CSS and JS<br>
<ydaniv> ... the include in @import prelude, to import based on a group?<br>
<fantasai1> s/very generic/because it re-used XML which is very generic; but it also had a "compact" syntax, which was designed for humans and tailored to the language, and was much much easier to read and write/<br>
<ydaniv> noamr: I think import already has conditions, right?<br>
<ydaniv> SebastianZ: yes, but import based on rout<br>
<ydaniv> s/rout/route/<br>
<astearns> ack emilio<br>
<ydaniv> emilio: it's an option to add it to conditions, but you'll get a FOUC<br>
<fantasai1> We have window.location, so I think "location" is a better word than "route" here.<br>
<ydaniv> ... a reason to add it to @media you'll get a lot of other stuff for free<br>
<bramus> q?<br>
<bramus> q+<br>
<ydaniv> ... that may also give you the import thing<br>
<ydaniv> ... probably @media will be a better option<br>
<ydaniv> noamr: one thing that could affect the future is to able to use pseudo-classes rather than @-rules<br>
<flackr> q+ to ask relation to :target<br>
<ydaniv> ... it's more of nested thing, it's more like lang, which can be nested<br>
<ydaniv> ... but no objection to any suggestion<br>
<astearns> ack kizu<br>
<ydaniv> kizu: really interesting, can be used with forms<br>
<ydaniv> ... however, under security and privacy considerations, can be used with query params and be used to extract stuff from there<br>
<ydaniv> noamr: so far out internal sec team hasn't come with issues, maybe just with nested routes, but those aren't designed yet<br>
<ydaniv> ... we may need to take more care there<br>
<ydaniv> ... the routes themselves include query params, things like values that go into forms would ordinarily go into the query params and these are not exposed to CSS<br>
<ydaniv> ... but not everything is final security wise<br>
<ydaniv> bramus: I like it, needed it before. Regarding naming, there was route-location, there are many things today called routes, maybe we should adopt this terminology<br>
<ydaniv> ... there's a need to allowing rules of whether this was from A to B<br>
<SebastianZ> q+<br>
<astearns> ack bramus<br>
<astearns> ack flackr<br>
<Zakim> flackr, you wanted to ask relation to :target<br>
<ydaniv> flackr: the simple use-case, the :target pseudo, can be used with route to make things visible/not<br>
<ydaniv> ... to be able to use :target with in routes<br>
<ydaniv> noamr: the problem with :target is that it is an exact match, and they may be other things that are not exactly matched<br>
<ydaniv> ... another problem is that it directly goes with links, and you have to put :has() on everything, it's a perf hotspot<br>
<bramus> s/... there's a need to allowing rules of whether this was from A to B/... there's a need to allowing rules of whether this was from A to B. Example use case is conditionally enable View Transitions using the view-transition at-rule based on the navigation source or target.<br>
<ydaniv> ... if you actually have a link that's linking to the current route then I want to style it with :target<br>
<ydaniv> fantasai1: isn't it where you land on a link?<br>
<ydaniv> noamr: it's the link<br>
<ydaniv> fantasai1: not what you're trying to do here<br>
<ydaniv> flackr: if this is an extension of :target, maybe reuse that name?<br>
<ydaniv> noamr: I think we can use the name where it makes sense, it's not necessarily about elements, there's sometimes no element in there<br>
<ydaniv> fantasai1: what is the :navigation-target?<br>
<ydaniv> noamr: it goes to a route that matches a link you clicked<br>
<ydaniv> fantasai1: so while you're navigating there, there's a link that points there and you want to point to it?<br>
<ydaniv> noamr: yes<br>
<ydaniv> ... if you have next/previous and/or number<br>
<ydaniv> ... or you want to go to expand view<br>
<astearns> ack SebastianZ<br>
<ydaniv> ... link in history navigation, it's like an expansion to...<br>
<ydaniv> SebastianZ: also wanted to ask, you had the id of the article, is it in your proposed syntax?<br>
<ydaniv> noamr: yes it's in there<br>
<ydaniv> SebastianZ: if you want to style based on parts inside that syntax?<br>
<ydaniv> noamr: didn't go that far yet, you can check for a parameter and do something specific<br>
<ydaniv> astearns: shall we conclude here?<br>
<ydaniv> noamr: yes, no need to resolve on anything<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-3200430286 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 11:49:45 UTC