- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 12:31:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Figure out a way to make hit-testing work on live (new) elements during a view transition`. <details><summary>The full IRC log of that discussion</summary> <ntim> noamr: This came up a lot, and still an issue rn, the VT pseudo elements don't follow hit testing, clicking the VT pseudos don't do anything meaningful, it goes to the doc element, there's a desire from web dev to make it do something<br> <ntim> noamr: there's a desire to make the VT pseudo a proxy for the actual element<br> <ntim> ...the kind of idea we discussed at google to use the pointer events prop for this and say that by default in the UA stylesheet they're `pointer-events: none` and then overriding it would start routing events<br> <emilio> q+<br> <flackr> strong preference to avoid a new pointer-events value and reuse auto/none if we can<br> <ntim> ...or change the default to another option, but we don't know about web compatibility<br> <flackr> q+<br> <ntim> something a bit weird about this hit testing, is that the document coordinates of the event and the local coordinates of the event are not in sync, they're in sync with another transform<br> <ntim> it's a bit weird, but it's probably OK<br> <astearns> ack emilio<br> <ntim> emilio: my main concern is what happens if the transitioned element is not hittable (it's behind something else), it breaks the user expectation. What is the expected behavior?<br> <ntim> noamr: if it's occluded, it would be non-occluded during transition<br> <ntim> emilio: you have 2 competing pointer-events value, the one from the image and the one from element<br> <ntim> flackr: the pointer events on the VT pseudo determines whether you can hit that pseudo<br> <ntim> flackr: ??<br> <flackr> s/??/unless they are both effectively pointer-events: auto, you don't hit the element<br> <ntim> emilio: you have to have pointer-events: auto on both captured element and pseudo-element for pointer-events to go through<br> <ntim> emilio: you would still need to look at PE: none in the subtree<br> <ntim> emilio: it seems implementable?<br> <ntim> I still find it a bit weird? not how anything else behaves normally<br> <bramus> q+<br> <ntim> emilio: this would make hover styles work in a fun way?<br> <ntim> emilio: not opposed, curious about the use case<br> <ntim> emilio: you have a long transition but want to interact it somehow??<br> <ntim> emilio: any precedent on mobile platforms?<br> <ntim> noamr: VT are weird to begin with<br> <kbabbitt> q+<br> <astearns> q+<br> <ntim> noamr: especially the VT-new pseudo-element which is a proxy<br> <ntim> emilio: it's a proxy but also an image because you can resize<br> <ntim> noamr: I would say iframes ??<br> <ntim> noamr: it's weird but consistent with the VT-new pseudo works<br> <ntim> noamr: you want to reverse proxy hit testing in a symmetrical way with painting<br> <ntim> noamr: use case that came to mind is scroll-driven VT or long VT, where the timeline is driven by scrolling, it's something people are doing<br> <ntim> many times it's just a matter of a slightly longer VT, and wanting things to feel interactive<br> <ntim> emilio: should we make the old pseudo pointer-events: none so it's transparent to hit testing ?<br> <ntim> emilio: especially if the old version is translated??<br> <ntim> emilio: imagine you're transitioning the old snapshot on top of the new one, where the old one slides up, I don't think hovering over the old one should hit test under it<br> <ntim> noamr: right now old hit tests to document<br> <ntim> emilio: if we make it none, then we might have odd behavior<br> <ntim> emilio: should we make it none or auto?<br> <ntim> noamr: need to think about it<br> <ntim> flackr: we propose that they're both pointer-events: none and authors should opt-in<br> <ntim> noamr: the VT root has pointer-events: auto<br> <ntim> (VT root means ::view-transition)<br> <emilio> q+<br> <ntim> flackr: I think about this as transforming an element, so we should make this consistent with transforming an actual elements, we already have an inconsistency where the local coordinates within an element is in a different space than the space of the event. my goal is to make this all consistent.<br> <SebastianZ> +1 on flackr's comment<br> <ntim> noamr: transforming it and putting it in a different place for stacking<br> <ntim> emilio: VT doesn't affect getClientBoundingRect, so consistency isn't really fully achieved<br> <astearns> ack flackr<br> <emilio> ack emilio<br> <astearns> ack bramus<br> <bramus> https://view-transitions.chrome.dev/cards/spa-auto/<br> <bramus> https://modernwebweekly.substack.com/p/modern-web-weekly-53#media-7e851d50-12f3-41a9-87c9-f0275cf048aa<br> <ntim> bramus: use-cases: you can delete cards, as one gets removed, you might want to keep clicking the delete button for the other ones<br> <flackr> most common however is I think just not wanting your page to be unresponsive. Users will click links before your transition fully finishes.<br> <ntim> bramus: add tags to an input and you want to click a tag while a transition is running<br> <bramus> https://codepen.io/bramus/pen/BabRVLg<br> <ntim> bramus: scroll-driven VT<br> <ntim> back button should be clickable<br> <astearns> ack kbabbitt<br> <ntim> kbabbitt: I'm curious about a11y implication. if an element is clickable, it should also be keyboard accessible. How does it work with tab order?<br> <ntim> flackr: they're not focusable<br> <ntim> emilio: per spec, they're not focusable<br> <ntim> emilio/noamr: per-spec, considered invisible<br> <ntim> e.g. not focusable or hit testable<br> <ntim> flackr: with the current spec, you would lose focus (changing focus styles) and lose tab order of things, maybe this didn't matter for whole document VT, but might be important for scoped VT to accomplish animation<br> <ntim> kbabbitt: I'm wondering, given that, does it make sense for both old and new to be hit-testable for tab order?<br> <ntim> flackr: old state stops existing completely<br> <ntim> kbabbitt: This is about making new state hit testable? whereas before it would do nothing<br> <ntim> astearns: 1. Are there patterns to follow in other UI toolkit? (android/iOS)<br> <ntim> noamr: idk<br> <ntim> flackr: This comes up because users are going to interact with stuff before transitions finish<br> <ntim> noamr: CSS animations are prior art, things work as stuff keeps animating<br> <ntim> astearns: Occlusion, old and new will pointer-events: none but you can opt-in to having a new have p-e: auto, but in a case where you are revealing the new by transitioning the old, you have to use p-e: auto to avoid clickthrough<br> <ntim> noamr: these elements would fallback to the ::view-transition pseudo<br> <ntim> astearns: so you would not have to change the old, because they would be captured by the ::view-transition pseudo<br> <astearns> ack astearns<br> <ntim> noamr: We need to deal with keyboard navigation before resolving on this<br> <ntim> bramus: aren't these separate?<br> <ntim> noamr: if you make a button clickable during the VT, but it goes out of tab order, then it creates a weird inconsistency during the transition<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10930#issuecomment-3200568288 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 12:31:15 UTC