Disabling UA transitions for same-document navigations

[khushalsagar]

I'm requesting a TAG review for an API to disable UA transitions for same-document navigations.

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.

• Explainer¹ (minimally containing user needs and example code): Explainer. This review is for the API specified here.
• User research: [url to public summary/results of research]
• Security and Privacy self-review²: None. The API is limited to same-document navigations.
• GitHub repo (if you prefer feedback filed there): None. I'd appreciate feedback in comments on this review.
• Primary contacts (and their relationship to the specification):
  • Khushal, Google
  • William, Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5206595333521408

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): CSSWG
• The group where standardization of this work is intended to be done ("unknown" if not known): CSSWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by:

The CSSWG issue for discussing this proposal is w3c/csswg-drafts#8747.

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

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify khushalsagar.

[torgo]

Hi @khushalsagar we're taking a look at this today and realized there are 2 reviews that are both referencing the same explainer. Can you give a bit more context on why these are 2 separate review requests? For the disabling we're slightly concern that disabling a browser feature like this might cause user confusion. We're more positive on #834 where being able to detect the presence of a navigation animation seems fairly benign. Have you discussed this user confusion issue?

[khushalsagar]

Can you give a bit more context on why these are 2 separate review requests?

Sure. We found 2 separate problems with choosing between a default transition designed by the UA vs a custom transition designed by the author:

• There are some cases where the browser UX is such that it's not possible for the site to customize the transition. Imagine a film strip type visualization of the navigation history. For these cases, the UA transition always wins and we just need a hook to inform the site of this choice. Detect UA Transitions on Same-Document Navigations #834 handles that.

• There are some cases where if the author designs a transition, it should be given preference over the default UA transition. Easiest example would be clicking the back button on a desktop browser. It makes sense for the custom transition on the site to win instead of overriding it with a UA transition. But there's currently no way for the site to indicate to the browser that it has designed a custom transition for a navigation. Such use-cases needs a different API (which this issue is about).

That said, I heard similar feedback against disabling any existing browser UX (like transitions on swipe gestures) that users are accustomed to at HTML WG. So this proposal needs more refinement. I can close it for now and reopen with more details. Does that sound reasonable?

Until there is a proposal here, browsers will have to be conservative about which cases have a UA transition (which overrides a site's custom transition). Since #834 will let sites detect these cases, it will be sufficient to not cause breakage because of "double transitions".

[torgo]

Ok thank you @khushalsagar for that reply and explanation. Much appreciated. I think it does make sense to close this for now and let's re-open when you have a refined proposal. As noted, we're happy with #834. Thanks! ✨