[css-view-transitions-1] The ability for authors to re-enable pointer events

[jespertheend]

I'm currently trying to make the below animation work using the view transitions api.
As you can see, the 'Subscribe with Google Pay' button is not clickable until the 'More payment options' link has appeared.
The same is true for the 'yearly billing' checkbox as well. This is because the modal itself is being resized as part of the same view transition.

The 'More payment options' link has a long delay for demonstration purposes. I intend to shorten the delay in the final result, so creating a second view transition for just that button isn't really an option either.

Screen.Recording.2025-01-29.at.15.09.18.mov

[bramus]

The problem you are having is that the ::view-transition overlay is catching all the clicks.

You can undo that by setting pointer-events to none on it.

::view-transition {
  pointer-events: none;
}

Note that the animated pseudos also don’t respond to hit testing, which can’t be undone.

See https://www.bram.us/2025/01/29/view-transitions-page-interactivity/ for more details.

[jespertheend]

Hey sorry I should have mentioned that I have already applied both

::view-transition {
  pointer-events: none;
}

and

:root {
  view-transition-name: none;
}

But in this case two buttons are animating and one finishes sooner than the other, unnecessarily keeping one of them unresponsive. So I can't really use these fixes here.

So what I'm asking here is for a way to individually control when each group's pseudo elements get removed and elements in the real dom become visible again.

You can’t undo this unresponsiveness on the groups and for good reasons:

• The location on screen does not match the actual element’s location
• What should be done when two different elements are transitioning from the one to the other: you could see the old one screen but then clicks would have to go to the new one?

I don't think these are an issue here. Since for this use case the animation of the individual group is already done, so swapping it out for the real dom prematurely shouldn't require any complex hit testing.

[bramus]

So what I'm asking here is for a way to individually control when each group's pseudo elements get removed and elements in the real dom become visible again.

I see. Different type of request indeed. Reopening.

[bramus]

The React folks are also asking for a way to re-enable pointer events on elements that participate in a View Transition – see facebook/react#32656 (comment)

(#) Although maybe it would be better to allow hit testing for simplicity.

While I’m hesitant to try and pursue this because you are not actually clicking the element which might be at a different visual position, it might perhaps be possible to allow this in certain specific situations:

• With scoped transitions (Note: this immediately makes this not work with Cross-Doc VTs)
• When there is only a ::view-transition-new(), or when the::view-transition-old() is display: none’d.
• When the ::view-transition-group() is not moving/resizing
• When it’s the same element that is transitioning (Note: this immediately makes this not work with Cross-Doc VTs)
• …

(Or perhaps combination of all these)

[noamr]

Proposed direction from internal sync:

• Change the behavior of pointer-events: auto in the ::view-transition-new pseudo element to forward the events to the originating element. This would be the inverse of painting the live snapshot of the element.
• We can probably keep that as the default. If we want to have the current behavior as the default behavior, we can have a UA stylesheet ::view-transition-new(*) { pointer-events: none } which would make the events fall to the ::view-transition-image-pair element, and the author can opt-in to the forwarding behavior.

Optionally, in addition, we could transform the actual originating element to match the ::new pseudo so that its getBoundingClientRect calls etc match its visible location.