[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: WICG/view-transitions#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.

[vmpstr]

I'd like to explore this further. One of the main hallmarks of identifying a view transition is that you don't get any hover effects or pointer changes (say over text) when hovering over a view transition pseudo that represents some element. That seems bad.

It becomes more of an issue for long running animations or animations in a paused state driven by something like a scroll timeline or other user interactions.

I suspect it also will become more of an issue in scoped transitions if the prevalence of small scoped transitions increases.

I'm thinking that a pattern could be something like setting pointer-events: none on the old pseudo, and pointer-events: forward (as a strawman) on the new pseudo which enables forwarding pointer events from that pseudo to the element being represented. This would map the event to the coordinates of the new element and let it capture and bubble starting at the actual element.

One downside is that, as far as I know, pointer-events: forward would only be applicable to ::view-transition-new. One other possibility is it would be something like pointer-events: forward(#foo) where #foo is an element id to which to forward events. This could apply in more cases, but opens the door to security considerations (e.g. clickjacking). Yet another possibility is to have pointer-events: auto do the magic thing on ::view-transition-new, but of course without another keyword this precludes the possibility of actually handling the click on the new pseudo without forwarding.

/cc @bramus

[bramus]

pointer-events: forward on the ::new to forward to the original element seems very reasonable and straightforward.

But:

1. It won’t entirely solve the “main hallmark of identifying a view transition” issue though, as the ::view-transition-new is obscured by the ::view-transition-old in the tree while they fade in/out. So the ::view-transition-old would still capture the clicks.
2. It’s a property value that would only do something on ::view-transition-new, which seems a bit weird.

To work around the first issue, authors need to hide the ::view-transition-old and not animate the ::view-transition-new which only works when the old and new are the same (modulo its size).

Perhaps we could do it all in one swoop, in which authors declare “something” to indicate that only the new should be captured (shown?) and that pointer events (via the group?) should be forwarded to the new state element? Something like view-transition-tbd: only-new?

[vmpstr]

1. It won’t entirely solve the “main hallmark of identifying a view transition” issue though, as the ::view-transition-new is obscured by the ::view-transition-old in the tree while they fade in/out. So the ::view-transition-old would still capture the clicks.

pointer-events: none on old should resolve this, right?

2. It’s a property value that would only do something on ::view-transition-new, which seems a bit weird.

Yeah, absolutely. I don't know if there's anything else where pointer-events: forward may make sense. Maybe with drawElement on canvas? Although that's not a feature as of yet

Perhaps we could do it all in one swoop, in which authors declare “something” to indicate that only the new should be captured (shown?) and that pointer events (via the group?) should be forwarded to the new state element? Something like view-transition-tbd: only-new?

Yeah that could be one way of doing this, and also solves the problem of inefficiencies when we're capturing old only to find that new is exactly the same. I am a little worried that there may be cases where we do want an old-new cross fade, it's just we want hover effects on the new to work as things are appearing. Perhaps we can switch the order of old and new: right now old is on top, which is why it intercepts the pointer events but it doesn't have to be?