[css-view-transitions-2] Should ViewTransition on cross-document navigations allow entry animations

[khushalsagar]

#8048 details the syntax for a Document to opt-in to ViewTransitions on cross-document navigations. What happens if the old Document doesn't have this opt-in but the new Document does.

This could be used to do entry animations, like fading in the content of the new Document.

[noamr]

In case of transitioning-from-blank, what's the advantage of view transitions? There's no detailed "old" state which is where VT can do things regular css animations can't. The developer can use regular keyframe animations, and reuse animation names with VT.

[khushalsagar]

Fair point, if you want to do an animation with the root content of the new Document, that can be done with CSS animations itself.

I'm good with not doing a ViewTransition unless both Documents opt-in. @vmpstr was curious about this use-case.

[vmpstr]

In case of transitioning-from-blank, what's the advantage of view transitions? There's no detailed "old" state which is where VT can do things regular css animations can't. The developer can use regular keyframe animations, and reuse animation names with VT.

Generally, the answer is simplicity. It's a similar answer to why have SPA view transitions. Entry animation with only "opt in to view transitions" is easier than any particular keyframe / animation set up that the developer could do.

I'm also fine with not doing the transition, if that's easier, I was mostly wondering if there is a use-case here that could be easily solved.

[noamr]

In case of transitioning-from-blank, what's the advantage of view transitions? There's no detailed "old" state which is where VT can do things regular css animations can't. The developer can use regular keyframe animations, and reuse animation names with VT.

Generally, the answer is simplicity. It's a similar answer to why have SPA view transitions. Entry animation with only "opt in to view transitions" is easier than any particular keyframe / animation set up that the developer could do.

What would you be opting in to? Entry animations don't have an "old" state so they're inherently different in most cases than the old->new animations. To make them meaningful, you'd have to define keyframes especially for this case, e.g. to slide-in an element from "somewhere" rather than from the previous location. If you do that, why not just set those keyframes on the element itself rather than rely on captures and a new syntax?

I'm also fine with not doing the transition, if that's easier, I was mostly wondering if there is a use-case here that could be easily solved.

Do you have an existing page to play with a use-case? I want to see if the current solution is lacking (applying keyframes on the actual element when there is no view-transition).

[vmpstr]

Entry animations don't have an "old" state so they're inherently different in most cases than the old->new animations. To make them meaningful, you'd have to define keyframes especially for this case,

In single-page-app view transitions, the default entry animation is to transition opacity from 0 to 1 while keeping the position/size at their destination values. Whereas I agree with you that one can design better animations, that seems to be a reasonable default that looks sufficiently different from not having an animation whatsoever

[vmpstr]

Do you have an existing page to play with a use-case? I want to see if the current solution is lacking

I don't have a page in mind. There may be two reasons for the fact that these pages don't seem to be prevalent: either developers don't want an entry animation, or the entry animation is sufficiently difficult to make that it's not worth the effort. I don't know which it is. If it's the former, then let's not do an animation here, but if it's the latter, it seems a fairly easy capability to add in this feature

[khushalsagar]

Summarizing a conversation today:

1. This seems like a nice-to-have because its pretty easy to polyfill. Authors can use startViewTransition to do an entry animation by starting with a display: none DOM.

2. While we want to encourage authors to write custom transitions when navigating between same-origin pages, it's better if cross-origin navigations don't have entry animations on the new Document. This avoids author transitions interacting badly with browser defined transitions. And browser transition makes more sense for cross-origin navigations anyway (since its no longer the experience within one site).
   Caveat: The spec does allow the UA to skip cross-document ViewTransitions if there is a UA transition that takes precedence.

3. Its going to be rare for same-origin navigations to hit this case, authors will likely design a transition with the old Document in mind.

4. Even if we want to support this case, it should be an explicit opt-in. For example, from: none in the opt-in. Authors will be surprised if an opt-in on the new Document also causes entry animations. This opt-in can be added later if we see demand for it.

Proposed Resolution: View Transition is only triggered when both the old/new Document opt-in.

[vmpstr]

I believe that's what the current spec dictates, right? If so, this is close, no change