#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

Discussed Jul 1, 2023 (See Github)

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>
Discussed Jul 1, 2023 (See Github)

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

Comment by @torgo Jul 17, 2023 (See Github)

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?

Comment by @khushalsagar Jul 17, 2023 (See Github)

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. #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".

Comment by @torgo Aug 3, 2023 (See Github)

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! ✨