- From: vmpstr via GitHub <noreply@w3.org>
- Date: Tue, 17 Jun 2025 19:20:57 +0000
- To: public-css-archive@w3.org
> 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? -- GitHub Notification of comment by vmpstr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10930#issuecomment-2981580244 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 17 June 2025 19:20:58 UTC