#835: Disabling UA transitions for same-document navigations

Visit on Github.

Opened Apr 21, 2023

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):
  • 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 https://github.com/w3c/csswg-drafts/issues/8747.

If an author chooses to disable UA transitions for a subset of navigations, they will need to use the API proposed at https://github.com/w3ctag/design-reviews/issues/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.

Discussions

2023-07-17

Minutes

Tess: if you have a browser that has a pretty UI effect... I think it's what the user of the browser expects... If authors could cause that to be disabled it could cause the user to be confused...

Dan: it's the same explainer.. [leaves comment]

Tess: they're trying to add features to add some of the appealing user interface abilities of single page apps. The motivation seems reasionable. Detecting the case wehre the UA is doing an animation is fine, because you want to make sure you don't also do one. But if you're doing a navigation in a browser that does som ekind of visual transition as part of its basic regular operating, you're just going to confuse the user and they're going to think something is broken

<blockquote> 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? </blockquote>
2023-07-mos-eisley

Minutes

Tess: disabling worries me - pretty core to the UX of Safari (e.g.)...

Dan: response

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.

Tess: it's an interesting assertion .. in the swiping case... wouldn't want to override.. so it's counterintuitive to me... but let's close for now.

clsoed with resolution too early