Re: [w3ctag/design-reviews] Cross-document View Transitions API (Issue #851)

We were happy to see cross-stakeholder support, though we'd like to see WebKit’s position as well. We also liked the secure-first design, with two-way opt-in and a same-origin restriction. Is cross-origin a non-goal because there are few use cases for it, or because you are not confident in the security of a cross-origin opt-in?
  
It seems a little inflexible to have the opt-in be HTML (as you point out); A CSS mechanism would indeed be preferable, though the proposed syntax is not idiomatic to CSS, since there is no precedent of @-rules that take values (this does not necessarily mean this is a bad idea, but when something creates a new precedent, we should spend extra effort to make sure there is no alternative design that is more [consistent](https://w3ctag.github.io/design-principles/#consistency) with the existing Web Platform without sacrificing usability.
  
Props for a declarative-first API too!
  
We had a few questions, that we didn't find the answers to in the explainer:
- What happens when both documents opt in, but there is no JS to customize the transition?
- What is the user experience on a very slow connection? We see there is an implementation-defined timeout, we do worry that clicking on a link, then nothing happening, then suddenly a transition could result in jarring user experience.
- What is the user experience if one part of the code customizes the transition parameters, and another calls `event.preventDefault()` so the navigation never actually happens? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1618893036
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/851/1618893036@github.com>