- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 17:00:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-navigation-1] :link-to() pseudo-class for links that are related to the current navigation`. <details><summary>The full IRC log of that discussion</summary> <ntim> dbaron:<br> <ntim> dbaron: The last time I talked about the spec in a WG, I said that pseudo-class for links were in the draft, but there was nothing to look at<br> <ntim> ... I want to talk to you about it, because they're interesting<br> <ntim> ...one of the things that this spec does, is make it so you can declaritively start VT depending on cases<br> <ntim> one of details to list and list to details transitions<br> <ntim> there's an issue in CSSWG drafts that is very old with a lot of these<br> <ntim> in many cases, you might have an UI that presents a list of things (list of movies)<br> <ntim> so not just pure text, could be text + thumbnail<br> <ntim> when you click an item, it navigates to a view with info<br> <ntim> you might want a VT where the thumbnail becomes a larger image<br> <ntim> and title becomes a larger title<br> <ntim> this is a natural use case for VT<br> <ntim> one of the nice things about setting this up declaratively is picking up the link you navigated with<br> <ntim> the URL keeps relationships<br> <ntim> Doing this declaratively needs a feature where you can have selectors where the link points to<br> <astearns> s/selectors where/selectors for where/<br> <ntim> The interesting thing with these selectors is the ability to do non-exact matches<br> <ntim> people can do this with JS<br> <ntim> If we do this declaratively, people might need to fallback to JS in some cases, but if that percentage is 50%, the API is not useful<br> <astearns> q+<br> <ntim> we need an API that covers enough use cases<br> <ntim> We want an API that matches where the links points to, with where you're navigating from/to<br> <ntim> you also want a selector that says which part you care about matching<br> <ntim> there are 3 pieces<br> <ntim> URL of the link, URL of the page.<br> <ntim> the selector that says how to match the two and which pieces have to match or don't<br> <bramus> q+<br> <ntim> This makes the selector design a bit interesting relative to how we design selectors<br> <ntim> what I have in the draft right now<br> <ntim> we came to the conclusion that people don't like it<br> <ntim> let's talk about the draft<br> <ntim> @route to declare URL patterns<br> <ntim> you can also use URL patterns directly, but easier to name it<br> <ntim> we have `with navigation-param(id)`<br> <ntim> The part that we don't like is that we need to match the two parts of the pattern<br> <ntim> It's compact, but packs too much in the current syntax to be readable<br> <ntim> bramus will talk about an alternative<br> <astearns> ack bramus<br> <ntim> bramus: I left a comment on the issue<br> <bramus> bramus: As it is currently proposed, a:link-to(--movie-details with navigation-param(id)) always matches the :id used in the targeted a element with the navigation-param(id).<br> <ntim> bramus: I don't think that covers all cases<br> <ntim> ...what about doing abirtary matches (matching a certain number)<br> <ntim> it's currently not possible to match with a certain part of the parameters<br> <bramus> `a:link-to(--movie-details with (:id = navigation-param(id)))`<br> <bramus> `a:link-to(--movie-details with (:id = navigation-param(favorite_id)))`<br> <ntim> suggestion is to allow specifying which named parameter of the route they want to compare against<br> <ntim> one thing to note, if we introduce this equals syntax, we can extend it later to do syntax like (:id > ..)<br> <dbaron> ... useful for directional view transitions, e.g., slide to left or right depending on page number<br> <ntim> astearns: is this declarative way giving more power than script? can we do this declarative stuff in script?<br> <ntim> astearns: can people rely on script for everything right now?<br> <astearns> ack astearns<br> <ntim> dbaron: I think they can<br> <noamr> q+<br> <ntim> dbaron: if you're relying on script, you're no longer using CSS for a big chunk. That script has a few disadvantages: hard to get all the cases, because there's a lot of pieces, you can't do this in little pieces<br> <ntim> astearns: we need to make this feature complete enough that people don't fallback to script, but that means we might take longer. So we might want to check existing libraries. For VT, there's no existing libraries, so maybe we should wait before working on this<br> <bramus> q+<br> <astearns> ack fantasai<br> <ntim> fantasai: I'm trying to understand this proposal. So you have a link and you're trying to compare against what it links to<br> <ntim> dbaron: navigation-params has a bunch of paramters that you can pull out from.<br> <ntim> fantasai: it's checking the to with the current URL right?<br> <ntim> dbaron: these selectors are going to setup VT-names against different pieces. It might be that you're going from the list to the details page or vice-versa. So you might care about the link from the list page or the link from the to page<br> <ntim> noamr: i wanna show a demo that might be easier to understand<br> <bramus> Demo URL: https://dwa-movies.onrender.com/ (Chrome Canary with flags)<br> <ntim> noamr: we have a list of movies, we can from a movie to a cast member, and we go back and forward<br> <ntim> noamr: the movie is always transitioning the hero<br> <ntim> if I have a thumbnail that goes to person with a matching movie, or a movie with a matching person, then we have this style<br> <dbaron> noamr, we can't see your devtools fwiw<br> <ntim> noamr: this is the most used type of VT in the few years its been around<br> <ntim> ...this manages the lifecycle, when does the navigation start<br> <ntim> <missed><br> <ntim> fantasai: we've been talking about styling links, what if the thing you're trying to style isn't a link?<br> <bramus> Example of not styling the link, but the img: `a:link-to(items_detail with item_id: route_param(from, item_id)) img`<br> <ntim> dbaron: you can use :has()<br> <ntim> fantasai: what if there's no link, there's just a navigation?<br> <ntim> dbaron: the main use case is that the link is on one of the two pages, and the view transition name would be set globally on the other page<br> <ntim> bramus: if you wanna match something on a page based on its URL, you can use the `@navigation` to detect on which page you are right now and you can use selectors in there. `:link-to()` to sniff out the link<br> <ntim> fantasai: if you click on a link, and style on what navigation is happening?<br> <ntim> bramus: you'd use the `@navigation` at rule and use :link-to()` to sniff out the link<br> <ntim> fantasai: I might have 5 links from A to B, I need to know which link triggered th navigation<br> <ntim> bramus: there is a different issue<br> <ntim> dbaron: you might not want to condition the link on which link triggered it. because you make styles that don't work when you go back<br> <bramus> Issue to figure out which link triggered the navigation: https://github.com/w3c/csswg-drafts/issues/11801<br> <ntim> .... both pages might be conditioning based on a @navigation at rule, but both of them might also be on the :link-to<br> <fantasai> fantasai: If there are 5 links from A to B, how is :link-to being useful on page A?<br> <ntim> dbaron: it's not the core use case, this feature is targeting the use case where you have a list of different things.<br> <ntim> you might want to write other selectors<br> <ntim> fantasai: if you have a selector of the active navigation, why do you have to repeat the link in both @navigation / :link-to?<br> <ntim> dbaron: you might not want an exact match<br> <ntim> @navigation, you might want to match all actor pages or all movie pages. :link-to for a specific actor or movie<br> <bramus> q+<br> <ntim> fantasai: the spec needs more examples/explanation behind the motivation<br> <noamr> It's because string-matching URLs is super brittle<br> <astearns> q+<br> <ntim> dbaron: the part that's interesting in the example is that they're not using exact matches, you can match of pieces that are important to you<br> <astearns> ack ntim<br> <astearns> ack noamr<br> <ntim> noamr: string match URLs is brittle, you can't take an HREF and match it against an URL, it might have an extra parameter for analytics, using a URL pattern is the way we found<br> <bramus> https://gist.github.com/bramus/2e463f180be00e89d4b66b972ab95713<br> <emilio> bramus: this is a bunch of examples we want to cover<br> <emilio> ... this shows that knowing the link that triggered the navigation doesn't fix the issue<br> <emilio> ... this targets the link from details to navigation page<br> <emilio> ... on the details page then you want to have a photo<br> <emilio> ... on the other one you want to give the jaws link a specific v-t-name<br> <emilio> ... sniffing the link that triggers the navigation wouldn't be useful because that's only meaningful on the old page<br> <emilio> ... so that's why we need "link that linked to the old page"<br> <emilio> fantasai: thanks, that's helpful<br> <emilio> ChrisL: should we put those in the spec?<br> <emilio> bramus: probably<br> <emilio> fantasai: what's the diff between route-param and navigation-param?<br> <emilio> bramus: they're the same<br> <romain> q+<br> <emilio> ... extra from argument in route_param is the next item in the agenda<br> <astearns> ack bramus<br> <astearns> ack astearns<br> <emilio> astearns: perhaps we should just take this as an intro to the new part of the spec, add some more examples, come back when people have had time to digest it?<br> <emilio> romain: syntax feels a bit brittle / complicated<br> <emilio> ... lots of user idents / keywords<br> <emilio> ... maybe an at-rule is better to define how something should match<br> <emilio> ... then link-to just points to that at-rule<br> <emilio> astearns: makes sense to me<br> <emilio> ChrisL: don't we have a thing to separate user-defined identifiers to avoid conflicting with different names?<br> <emilio> bramus: yeah v-t-name is not a dashed idents<br> <TabAtkins> We only use strings when the value comes from outside and doens't necessariliy conform to ident rules, yeah<br> <emilio> fantasai: v-t-name is internal to css<br> <emilio> bramus: you could use dashed items but the spec only requires custom ident<br> <emilio> dbaron: sounds like we're not going to come to a conclusion right now<br> <emilio> ... want to keep trying to revise the spec<br> <emilio> ... if we're going to do the work of porting a bunch of examples I'd like to update the spec to something we're more likely to want<br> <emilio> astearns: yeah but without the examples it's hard to evaluate<br> <emilio> ... maybe we should iterate with the syntax and examples<br> <emilio> ... which is more work<br> <emilio> ... but probably worth it<br> <emilio> dbaron: I'd like to reiterate the syntax once before putting in the examples<br> <emilio> fantasai: that's fine<br> <emilio> astearns: still seems like we are not going to reiterate on the syntax right now<br> <emilio> dbaron: fair<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13163#issuecomment-3812577923 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 17:00:48 UTC