[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.)