Re: [csswg-drafts] Disabling UA transitions for same-document navigations (#8747)

Thanks for the feedback Nick, those are very good insights. Responses below.

> CSS vs JavaScript API

The benefit of a CSS API is reducing latency of the gesture since its declarative. We can start the visual animation as soon as the event is received from the OS. A script based API will require us to dispatch an event (cross-process) before the visual animation can start.

The handling of this gesture is also different from how touch events usually work. The common pattern would be to provide the touch event to script, and if it preventDefaults then the UA stops handling the gesture. In this case we don't want authors to be able to override what a swipe from the edge does:

* It has to trigger a navigation (as opposed to animating some content on the page).
* The target entry of the gesture is decided by the UA.
* Whether the gesture results in a navigation depends on how far the user swipes. That decision will be up to the UA.

The control authors have should be limited to whether there is a visual animation involving the web content as the user swipes. The reason for this is that the swipe gesture could be the only way for a user to go back on a browser. If the page is allowed to override it, they can effectively prevent the user from leaving the page.

This is why I don't think dispatching touch events to script for this gesture is a good idea. Authors might assume they can take over the gesture using preventDefault and start animating content on the page. We'll eventually need an API to dispatch the event stream for authors that want to customize the visual transition, but it seems better to have an explicit API indicating that the gesture will trigger a navigation (and the target entry).

That said, I can see a JS API which complements the CSS API for this. Do you have any use-cases in mind which won't work with just the CSS version?

> Is there a greater story where the CSS API is superior to JS, e.g. as part of interop with View Transitions?

For same-document navigations (which this proposal is targeting), it's agnostic to VT. Authors can use any other framework to do transitions during navigations.

For cross-document navigations, an API like this shouldn't be necessary. Since what this API conveys is explicit in that case. The only way to do a visual transition is using a primitive like [View Transitions](https://drafts.csswg.org/css-view-transitions-1/). VT would have a [declarative opt-in](https://github.com/w3c/csswg-drafts/issues/8048), so the UA already knows that the site has a custom transition for atomic navigations.

The UA can also suppress the site's custom transition (in favour of a UA transition) by not executing the ViewTransition for swipe navigations (until there is a way for authors to customize it).

This effectively means the UA can do the right thing without the need for any new APIs.  There is an open question [here](https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md#cross-document-navigations), if there are cases where a ViewTransition when the navigation commits is strictly better than the UA default. Did I miss any case?

> I believe it would still require JavaScript, so it could still be more natural to determine UA transition cancelling in the same place as startViewTransition().

That would actually be too late, authors would call `startViewTransition()` in the `navigate` event. This is dispatched when the user gesture has ended in a state that the navigation should be triggered. There won't be a `navigate` event if the user swipes back. The decision for cancelling the UA transition is needed when the user starts swiping.

> I'm not aware of any atomic default browser transitions

Me neither. :) We (Chrome) have discussed this and made sense to make the API future proof for that case.

> Not all swipe navigations are edge swipes. Specifically, UC Browser uses whole-page swipes for navigation as long as the element being touched doesn't have room to scroll, and doesn't prevent default.

That's interesting. In this particular case the browser is choosing between using the gesture for page content vs navigation. Even if the author doesn't preventDefault, I'd expect the `same-document-ua-transition` setting to suppress the visual animation same as an edge swipe would. Wdyt?

> One possible enhancement is some sort of [paint holding](https://developer.chrome.com/blog/paint-holding/).

That's an interesting idea. FWIW, Chrome will keep showing the preview until DOM changes after the `navigate` event are painted. I expect every UA implementation will need to do that to avoid a flash of pre-navigation content if the preview is dismissed sooner.

The API you mentioned is useful if there are cases where the frame after the `navigate` event needs to block on an async event. That sounds like generalizing the [rendering suppression](https://drafts.csswg.org/css-view-transitions-1/#document-transition-suppressing-rendering) concept in VT. If there are compelling use-cases, we can add an API like you proposed to allow authors to suppress rendering outside of VT.

-- 
GitHub Notification of comment by khushalsagar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8747#issuecomment-1533810994 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 3 May 2023 22:03:45 UTC