Intent to Prototype: Disabling UA transitions on same-document navigations

[Khushal Sagar]

Contact emails

khusha...@google.com, liuwi...@google.com

Explainer

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

Specification

None

Summary

Smooth visual transitions as users navigate on the web can lower cognitive load by helping users stay in context. It can also provide a visual cue about the destination before initiating the navigation. Both site authors and user-agents (UAs) add visual transitions to their navigations for these use-cases. However, the user experience is bad if both the site author and the UA add these transitions: the transitions may conflict and cause confusion for the user. The goal of this proposal is to avoid such cases to ensure only one visual transition is executed at a time.

Blink component

Blink>DefaultNavigationTransitions

Initial public proposal

https://github.com/w3c/csswg-drafts/issues/8747

TAG review

https://github.com/w3ctag/design-reviews/issues/835

TAG review status

Pending

Risks

Interoperability and Compatibility

The main interop risk with this proposal is whether UA transitions should be allowed by default or not. Allowing them by default has a compat risk of breaking sites which ship with custom transitions already. We could try to assess the impact with heuristics like "detect whether the Document is constantly animating for x seconds after firing popstate/navigate event" but it's likely to have false positives. Also note that Safari/Chrome on iOS already ship with UA transitions by default.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/784)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/177)

Web developers: No signals

Other signals:

Ergonomics

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

Security

The API lets the site author selectively disable UA transitions based on whether the navigation was predictive (swipe) vs atomic (button click). The author can then detect whether a transition occurred using the API proposed in https://chromestatus.com/feature/5204831477694464. This effectively means site authors can detect whether the navigation was swipe or atomic; and in turn whether the device supports a category of navigations. However, this information can already be derived using the UA string.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Is this feature fully tested by web-platform-tests?

No

Since the feature depends on whether the UA performs a visual transition on navigations (as a part of browser UX), it's difficult to write an interoperable WPT for this. The exact gesture which causes a UA transition is a browser's internal detail.

Flag name

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5206595333521408

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Khushal Sagar]

FYI, I added a visual example to the problem statement to clarify the current status.