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

> Hi @noamr!

Hi @LeaVerou, thanks for reviewing! Some answers inline.

> 
> 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?

We see same-site cross-origin as a potential future enhancement. And even that is not devoid of security (and other) issues. 
The main use case we heard from partners is around same-site, e.g. `landing.example.com` transitioning to `app.example.com`. Also, see one of the answers below: to make these transitions work well, in most cases both "sides" need to be coordinated with each other. Same-origin or same-site gives us a hint that there's some degree of coordination.

All that said, who knows what the future holds. It's mainly a non-goal for now to allow us to focus on what we know are important and feasible use-cases.

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

We're thinking the same... See [proposed update to this explainer](https://github.com/WICG/view-transitions/pull/211)
basically it would look more like
`@auto-view-transitions {
  same-origin: enable
}`

or some such, which would be consistent with @font-face and @page rules.
Happy to discuss the syntax with you, TAG, and the CSSWG and I'm sure we'll find the right syntax.

> 
> 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?

The transition happens, no need for JS. The JS API is useful for:
- observing whether there was a transition
- Skipping the transition
- Animating the transition's pseudo elements with the web animation API

But it's by no means necessary for the common case.

> * 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.

This is another reason why this would be challenging in a cross-origin setting.
It is indeed a possible scenario, however in a same-app environment (which is currently same-origin) the developer can mitigate it, deciding when to opt-in to these transitions and so forth.

The context where we see people using this is an "MPA", where the user journey in the entire app, across documents, is tested by the developer.

> * 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?

You mean if the old document starts the transition and the new document skips it? The moment the transition is skipped we'd render the new document's "final" (post-transition) state. This is not different from skipping a same-document transition.


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

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