Re: [csswg-drafts] [css-view-transitions-1] User input should be ignored when rendering is suppressed. (#7797)

Summary for CSSWG:

During a view transition, elements involved in the transition are hidden from the real DOM. In most cases, this means every element is hidden, because every element is somehow involved. However, if you set root's `view-transition-name` to `none`, you can scope a transition down to particular elements.

Clicks during a view transition will almost always hit one of the pseudos, because `::view-transition` fills the viewport. This means pointer events will apply to the document element. However, developers could change this by altering the size of `::view-transition`, or applying `pointer-events: none`.

But, what should we do while the `document.startViewTransition(callback)` `callback` has been called, but its returned promise hasn't yet settled. We freeze rendering during this, so what the user's seeing might not represent the elements beneath a particular point.

What should we do with clicks during this period?

Currently on the web platform, if you block the event loop, eg with a JavaScript `while` loop, it will also block rendering. If the user clicks anywhere, tasks are queued to perform hit-testing and events. If the DOM is changed just before unblocking the event loop, those clicks will now hit-test against a different document structure to the one the user felt they performed clicks against. It's not great, but it's what happens.

## Option 1: Queue user inputs

We prevent tasks being taken from the [user input task source](https://html.spec.whatwg.org/multipage/webappapis.html#user-interaction-task-source) during this period. It isn't a full event loop block, it just queues up input-related tasks.

Then, once the transition starts, the task source will be unblocked, and hit-testing will happen as normal.

There's a risk of deadlock. Eg, if `startViewTransition` is called on `pointerdown`, and the developer waits until `pointerup` or `pointermove` before resolving the callback promise.

This option also feels incompatible with scoped transitions, a future planned feature where multiple view transitions can run concurrently if they're scoped to independent elements.

## Option 2: Target pointer events to the document element

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.

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7797#issuecomment-1469931231 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 12:39:42 UTC