Disabling UA transitions for same-document navigations

[khushalsagar]

WebKittens

@smfr

Title of the spec

Disabling UA transitions for same-document navigations

URL to the spec

w3c/csswg-drafts#8747

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/view-transitions/blob/main/default-ua-transitions.md

TAG Design Review URL

w3ctag/design-reviews#835

Mozilla standards-positions issue URL

mozilla/standards-positions#784

WebKit Bugzilla URL

No response

Radar URL

No response

Description

If an author chooses to disable UA transitions for a subset of navigations, they will need to use the API proposed at #176 to detect whether a UA transition was executed for a navigation.

[annevk]

Discussing this with colleagues it seems that given we support #48 we should also be supporting this, i.e., "position: support". Please say something within a week if you disagree!

[khushalsagar]

@annevk apologies for not updating this issue. We're not pursuing an API which lets developers disable browser UX based on your feedback at the HTML WG discussion, TAG and discussing a related issue in the context of cross-document transitions at CSSWG here.

The summary for recommendation to browsers/developers is:

• The browser should decide when a UA transition takes precedence over the author's custom transition. This should be done conservatively, only for cases where authors can't customize.
• The web platform should strive to make more cases customizable to authors, the swipe gesture on Webkit based browsers is an example of that. We're not actively working on an API for this but its on our radar. Proposals for this are welcome.
• Developers should use the API provided in Detect UA Transitions on Same-Document Navigations #176 to detect when the UA has decided to execute a transition and suppress their custom transition.
  This is not required for cross-document transitions since a custom transition for them requires a browser primitive (View Transitions). The browser is already in control of whether a View Transition is executed or not and will not run them if a navigation is using UA transitions.

If the above sounds good to you, feel free to close this issue.

[annevk]

I guess it's not clear to me how the browser would know for a same-document navigation that there's a developer-provided transition?

I thought this was a proposal to disable that such that you can provide your own transition using view transitions.

[khushalsagar]

I thought this was a proposal to disable that such that you can provide your own transition using view transitions.

Yes, the goal of this proposal was to disable the UA transition such that the author can provide their own transition. It doesn't have to be a view transition, for same-document navigations the transition could be written using any framework or other web APIs directly.

We explored 2 API contracts:

1. The site tells us whether it has custom transitions (what this issue is about).
2. The browser decides between the site's custom transition and UA transition, which could depend on whether the site has a custom transition. The decision is communicated to the site using the proposal in Detect UA Transitions on Same-Document Navigations #176.

But the cases where we (Chrome) is planning to add UA transitions are limited and would currently always prefer the UA transition (see below). IIUC Safari has the same stance but correct me if I misunderstood.

So we've decided to only implement #2 for now, #1 won't change the browser decision. If we consider adding UA transitions for more cases (like link clicks) then we can revisit the API proposed in #1.

---

For cases where a UA transition would always be preferred. Safari right now does a transition as the user swipes so they can peek at the previous/next navigation entry before doing the navigation. If we let authors disable that then the UX would be:

• There is no change in the UI as the user swipes. Touch events for edge swipes (which provide the navigation gesture) are not consistently routed to the site across browsers so its not like the site can customize this transition. And its not trivial to implement so the site might still not do any animation when the user is swiping.
• Once the swipe is done, and its to a point that the browser decides to trigger the navigation, the site will get the navigate/popState event and run their custom transition.

That seems worse than the browser doing an animation which progresses with the user gesture. The long term thinking is to provide an API for the site to observe the gesture and make it easy to write a custom transition (with a new animation timeline + View Transition). When such an API exists, the author can tell the browser about their custom transition as a part of observing the gesture.