- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 16:30:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] User input should be ignored when rendering is suppressed.`, and agreed to the following: * `RESOLVED: target pointer events to the document element` <details><summary>The full IRC log of that discussion</summary> <JakeA> https://github.com/w3c/csswg-drafts/issues/7797#issuecomment-1469931231<br> <khush> Jake's getting 'em all! :)<br> <fantasai> s/Topic/Subtopic/<br> <fantasai> s/topic: break//<br> <emeyer> JakeA: During a transition, elements involved are hidden from the DOM<br> <Rossen_> q<br> <emeyer> …That usually means every element is hidden, because the root element has a transition name<br> <emeyer> …Clicks during a transition will almost always hit the pseudo and fall to the document root<br> <emeyer> …Authors could change this by changing the root’s transition name to none<br> <emeyer> …Question is: what do we do with clicks while promises haven’t settled and the transition is frozen?<br> <emeyer> …Similar case: if you block the event loop using a while loop, it will block rendering<br> <emeyer> …If a user clicks anywhere, those events are queueing up<br> <emeyer> …Once the freeze is thawed, the events and hit tests and such are resolved then, which may resolve hits against things that moved<br> <emeyer> …We can’t do a full event block, but we could take from tasksources and then resolve when the transition starts<br> <emeyer> …Deadlocks are still possible in this option, which may also conflict with scoped transitions<br> <emeyer> …We don’t want to block all input events while scoped transition is happening<br> <emeyer> …Option 2: we apply all events to the document element<br> <TabAtkins> q+<br> <emeyer> …In that case, a click may hit the document element whereas if we’d queued it, it might have hit a more specific element<br> <flackr> q+<br> <khush> +1 for option 2.<br> <emeyer> Rossen: I want to make sure we’re sticking to CSS<br> <emeyer> TabAtkins: +1 for option 2, which seems a little safer; also I hate when things resolve against DOM I wasn’t expecting; also makes things more predictable<br> <Rossen_> ack TabAtkins<br> <Rossen_> ack flackr<br> <emeyer> flackr: I think a common case is that by the time you’d dispatch the events in option 1, the elements will be where they should be<br> <khush> q+<br> <emeyer> …Worried that we’re seen cases transitions to move small pieces of sub-documents<br> <emeyer> …I strongly prefer option 1<br> <Rossen_> ack khush<br> <emeyer> khush: If we decide to buffer until rendering is done, the first question is do we dispatch before or after creating the pseudo-DOM?<br> <emeyer> …Why not just give it to the document?<br> <emeyer> JakeA: I think flackr’s point is that if you have a pseudo-element is in a certain place, option 2 raises the chances of a thing not being where it was when the click was made<br> <emeyer> khush: So this is for the case of rootless transitions?<br> <emeyer> JakeA: This is all about rootless transitions<br> <emeyer> flackr: If I start a transition on mousedown, as long as my pseudo is pointer-events: none, I can still get that click<br> <emeyer> …I also feel like you have a halting issue regardless, since there’s no requirement a transition ever finish<br> <chrishtr> q+<br> <emeyer> JakeA: Should have clarified that this deadlocks are already limited to four seconds<br> <emeyer> flackr: So this isn’t new, it’s just we could make them more likely<br> <emeyer> …If a developer doesn’t finish setting up for a view transition, there will be problems<br> <emeyer> chrishtr: With option 2, if the dev starts a transition but then does nothing and we wait four seconds, if the user clicks in that 4s window, is the click lost?<br> <emeyer> JakeA: Yeah, in option 2, the click won’t work<br> <Rossen_> ack chrishtr<br> <emeyer> chrishtr: So the default UA behaviors are suppressed<br> <khush> q+<br> <emeyer> flackr: In option 1, we wait for the transition to fail to start, the events are processed after the transition is canceled<br> <emeyer> chrishtr: Could we do an option 3 where user events are still processed and applied to the original target?<br> <Rossen_> ack khush<br> <emeyer> khush: Option 1 is very hard to reason about with scoped transitions, whichis why I’m advocating option 2<br> <emeyer> …The easiest thing is to dispatch an event at the root of the subtree,<br> <vmpstr> +1<br> <Rossen_> ack khush<br> <emeyer> flackr: An event targeted at the document provdes XY coords, yes?<br> <emeyer> khush: Yes<br> <emeyer> Rossen: We seem to be sliding to option 2; flackr, you were the main proponent of 1<br> <emeyer> flackr: I like that option 2 supports scoped transitions better<br> <emeyer> …I think it’s okay<br> <emeyer> Rossen: Any other opinions or objections to resolved on option 2?<br> <emeyer> (silence)<br> <JakeA> Target pointer events to the document element<br> <JakeA> This is what will happen during the transition in most cases anyway, except in the edge case mentioned above, where the root's view-transition-name is set to none, and the clicks don't hit the pseudos. In that case, click may hit the document element, where they would hit a more specific element during the transition.<br> <emeyer> RESOLVED: target pointer events to the document element<br> <flackr> Or to the root of the transition for future compat with scoped transitions!<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7797#issuecomment-1470359727 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 March 2023 16:30:17 UTC