[css-view-transitions-2] Figure out a way to make hit-testing work on live (new) elements during a view transition

[noamr]

When a view transition is ongoing, the new element is not rendered in its place, but its rendered image is projected into the ::view-transition-new pseudo-element. However, this is uni-directional: hit testing on the pseudo element is not forwarded to the actual element, and the originating element itself is treated as invisible (same as visibility: hidden or pointer-events: none).

Forwarding the events by default might be confusing, as the coordinates of the original event will not always match the coordinates of the element, e.g. in the case where the ::view-transition-group animation is overridden.

But perhaps there was a way to automatically forward these events, displaying both the original and the mapped coordinates?

@vmpstr @khushalsagar @nt1m

[nt1m]

I don't think it's worth implementing hit-testing tbh, there are many drawbacks:

• by default, the old and new snapshot cross-fade, it would be a confusing UX if some cross fading content responded to hit-testing
• closes the door for some optimizations on how to implement the live snapshotting
• etc.

[noamr]

I don't think it's worth implementing hit-testing tbh, there are many drawbacks:

• by default, the old and new snapshot cross-fade, it would be a confusing UX if some cross fading content responded to hit-testing

Not suggesting to implement this by default, but by some opt-in that makes it easier when it does make sense.

• closes the door for some optimizations on how to implement the live snapshotting

Does it? This is doable today in userland, it's just geometry mapping between where the element should be and where the pseudo element is.

• etc.

[nt1m]

Does it? This is doable today in userland, it's just geometry mapping between where the element should be and where the pseudo element is.

I'm a bit skeptical that it's "just" a geometry mapping if you also have to map clicks on children or account for features like nested view transitions.

[noamr]

Does it? This is doable today in userland, it's just geometry mapping between where the element should be and where the pseudo element is.

I'm a bit skeptical that it's "just" a geometry mapping if you also have to map clicks on children or account for features like nested view transitions.

I think it actually no more than geometry projection. In the end there is a quad somewhere on that screen that is a projection of the content of the originating element based on its border box. Nested view transitions don't change that, and that rectangle can be mapped to the element's non-participating descendants if needed.

[khushalsagar]

Supporting input routing is doable IMO, there's prior discussion on it here: https://github.com/WICG/view-transitions/issues/157. It does end up being a geometry mapping pretty much from the image to the DOM element.

The main use-case I've seen is interrupting a transition to start a new one. So we should do input if we can also figure out how to interrupt a transition and seamlessly start a new one.