#834: Detect UA Transitions on Same-Document Navigations
Discussions
2023-07-17
Peter: there was a long discussion in the CSS wg... I don't think anything about the detection was discussed. I think this is a simple one we can just close.
2023-07-17
Tess: had a conversation...
Tess: I think this is fine. There's something weird - a web-facing feature - exists because browsers differ on the way the render history transitions... like in Safari you do an edge swipe and you can see the page you're going back to. It feels weird that there's a web facing feature here... but given the use case - trying to stop a doulbe-animation - I think it's reasonable to have a straightforward workaround.
Dan: privacy
Tess: only revealing one bit of fingerprinting - whether you're using a browser that has this feature (animations) or not.. It's possible that there could be a feature that changes...
Dan: API itself doesn't reveal anything about the history - simply the mechanism of the browser...
Dan: put in proposed close and close at the plenary?
Tess to leave comment
OpenedApr 21, 2023
I'm requesting a TAG review for an API to detect UA defined visual transitions on 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/5204831477694464
Further details:
The html issue for discussing this proposal is here.
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.