[selectors-5] Add pseudo-class selector to target the element that initiated the outgoing navigation

[bramus]

Intro

One of the properties of the the Navigation API’s NavigateEvent is the sourceElement. From the explainer.

sourceElement: An Element or null, indicating what element (if any) initiated this navigation. If the navigation was triggered by a link click, the sourceElement will be the <a href="...">. If the navigation was triggered by a form submission, the sourceElement will be the the element that sent the submit event to the form, or if that is null, the <form> being submitted. The sourceElement will also be null when a targeting a different window (e.g., <a href="..." target="otherWindow">).

This property is shipping in Chrome 135 and other browser vendors are supportive of it (WebKit / Mozilla).

The request

It would be handy if it was possible to target the element using a CSS selector, e.g. something like :navigation-trigger or :navigation-source-element (name TBD, of course)

A use-case that is very common and would be solved by this are View Transitions where authors want to set a view-transition-name onto the element that was clicked. Think of an overview page with a list of links to detail pages. Typically they only want the one title or thumbnail to get a view-transition-name.

Right now they need script to set that View Transition name, whereas it would be nice to be able to just do that in CSS:

.list a:navigation-trigger img {
  view-transition-name: thumbnail;
}

I’ve personally had this need before (in this demo), and have also received requests from authors regarding this (example).

The lifetime of this selector

Something that would need to be thought are UA back / forward navigations. When clicking a link – which sets :navigation-trigger – and then hitting the UA back button the same transition should run (but in reverse) and then hitting the UA forward button it should also run again.

To solve that, I would say this new selector starts matching onto an element when the navigation gets initiated, but that unmatching is not linked to the navigation completing. Instead, existing :navigation-trigger matches get unmatched when the navigation gets cancelled. This can occur when a new navigation starts (e.g. you click a link, but then click an other one: only the last one is matched by :navigation-trigger) or when people hit the cancel button of their browser.

Alternatively some logic could be worked out where the last :navigation-trigger match of a page gets remembered and dynamically gets re-applied when the back/forward buttons are used.

(Admittedly this part is still a bit vague and needs more thought.)

[bramus]

/fyi @noamr @vmpstr

[Crissov]

If I’m understanding this correctly, the proposed pseudo-class would on the one hand belong to the same group as classic user interaction classes :hover, :focus, :active, :visited, but on the other hand would sometimes also be the opposite end of :target.

Like targets, origins or sources can either be identified by value or by action. That means, are all links (or buttons etc.) that result in the same target matched by this selector or just the one the user actually has interacted with (i.e. “clicked”)? Regardless, is there value in having both?

[bramus]

Just the one. The goal of :navigation-trigger is to identify the element that initiated the navigation. This is mirrored after NavigateEvent.sourceElement.

[Crissov]

Fine, to match Navigation API, a user action pseudo-class suffices, and the other semantics is probably caught closely enough by :local-link already, or perhaps more precisely :local-link:visited.

[bramus]

the other semantics is probably caught closely enough by :local-link already, or perhaps more precisely :local-link:visited.

Using :local-link:visited won’t work here, because that one matches the current location, whereas with the requested :navigation-trigger would match the next location. Additionally, :local-link can match more than one element, whereas :navigation-trigger can match only one single element.

Also note that elements such as a <form> can be the sourceElement of a navigation.

[noamr]

Thinking the following:

• I don't yet see a point in generalizing sourceElement's behavior with form. Do you ever need to style a form that is the source of a navigation in the same way you'd style a link that is the source of the navigation?
• Staying with links here, there are two possible links: the one that actually triggered the navigation, and one or more that match the remote navigation URL.

Given that, I think we can stay with the *-link pseudo-classes, and have:

• :remote-link - the counterpart of :local-link, selects the "non-current" URL in a navigation. Will work symmetrically for back navigations.
• :trigger-link or :active-link or :source-link: a link that actually triggered this navigation
• Both of these would only work during a navigation: from the point a navigation is initiated until the navigation handlers are done (and the navigation-triggered view-transition is finished, if exists).
• In addition see [css-view-transitions-2][css-conditionals] Exposing navigation/route matching #12594 for how this works with the concept of routes, where the URL matching doesn't have to be 1:1.

[bramus]

• I don't yet see a point in generalizing sourceElement's behavior with form. Do you ever need to style a form that is the source of a navigation in the same way you'd style a link that is the source of the navigation?

When submitting a search form, one might want to snapshot the input field (and possibly more elements of the form) for use with a view transition.

[noamr]

• I don't yet see a point in generalizing sourceElement's behavior with form. Do you ever need to style a form that is the source of a navigation in the same way you'd style a link that is the source of the navigation?

When submitting a search form, one might want to snapshot the input field (and possibly more elements of the form) for use with a view transition.

Sure, but would you style it in the same way as a triggering link? Wouldn't it be :source-form or something like that? Is there a use case where putting the source-link and source-form together for styling adds value?