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