Enable modifying the transition based on incoming state (SPA/MPA)

[jakearchibald]

One thing I've had trouble figuring out in the past is what to do with shared elements across two documents when scroll position is different between the two.

For instance:

• Both pages have a header.
• Page 1 is scrolled to the top.
• A link is clicked to page-2/#footer, which targets the bottom of the document.
• Page 2 is very tall.
• The transition is reveal-right

Should the header try to do a shared transition in this case? I think it'd look weird.

What if:

• Both pages have a header.
• Page 1 is scrolled 50px down
• A link is clicked to page-2/, which loads scrolled to the very top.
• The transition is reveal-right

In this case the header is in-viewport in both cases. I am not a designer (IANAD?) but it feels like animating scroll position is the most natural thing here.

Let me know if it isn't clear & I'll come up with some animated examples.

[jakearchibald]

I created some quick examples to illustrate the problem, and some possible solutions. Unfortunately, Chrome seems to have some timing bugs in web animations that occasionally break the demos, but it's solid in Firefox https://static-misc-2.glitch.me/page-transition/.

(it's totally broken in Safari)

[khushalsagar]

I'm trying to narrow down the feature request based on the examples in the comment above. We need an animation for the header and I don't think that needs to a paired transition. It closely aligns with the feature request in #37, we want a separate entry/exit slide animation for the header. The idea of a single element transition that we've discussed should cover this.

An excellent use-case this brings up is whether the transition should be modifiable based on the scroll offset. And I think this could be a general pattern of handling back navigations where the restored page was modified because of user interaction. This is how we got to the discussion of whether the incoming or outgoing page should decide the transition (@vmpstr fyi):

1. If the outgoing page is in charge then you can reasonably handle most navigations, since you know all state about the outgoing page and the incoming page should start in default state. There can be edge cases about how the incoming page is laid out (elements being offscreen or not fetched) but maybe that behaviour can be specified in a declarative way by the outgoing page.

2. Now consider the case of a back navigation. Ideally we'd want an automatic transition which does all animations in reverse (we should have a default mode like this). But the user could've interacted with the current page before hitting back and the previous page might be restored using BFCache. So now both the incoming and outgoing page could have been modified by user interaction. Also I'm assuming the outgoing page doesn't have a way to know if this back navigation will be a restore or a reload.

The 2) scenario is what makes me inclined towards having an API which lets the incoming page decide the transition.

[khushalsagar]

The rough sketch for the MPA API is here. And we agree that state on both pages is relevant for deciding the transitions.

The outgoing one tags based on its current state and can include opaque context data. The incoming one receives this data and decides the transition based on its own state.