It would be nice to be able to animate the transition between pages if we want to on the web without resorting to hacks or full-blown architecture choices to achieve it. I could imagine an API that would run stuff, perhaps integrating with WAAPI, before the page is unloaded, and other stuff after the next page loads in. This, with otherwise regular ol’ anchor links and page loads.
We do have an onbeforeunload API, but I’m not sure what kind of baggage that has. We can technically build page transitions now, even without single-page-app architecture, but what I want are purpose-built APIs that help us do it cleanly (understandable functions) and with both performance (working as quickly as clicking links normally does) and accessibility (like focus handling) in mind.
If you’re building a single-page app anyway, you get the freedom to animate between views because the page never reloads. The danger here is that you might pick a single-page app just for this ability, which is what I mean by having to buy into a site architecture just to achieve this. That feels like an unfortunate trade-off, as single-page apps bring a ton of overhead, like tooling and accessibility concerns, that you wouldn’t have otherwise needed.
Without a single-page app, you could use something like Turbo and animate.css like this. Or, Adam’s new transition.style, a clip-path() based homage to Daniel Edan’s masterpiece. Maybe if that approach was paired with instant.page it would be as fast as any other internal link click.
There are other players trying to figure this out, like smoothState.js and Swup. The trick being: intercept the action to move to the next page, run the animation first, then load the next page, and animate the new page in. Technically, it slows things down a bit, but you can do it pretty efficiently and the movement adds enough distraction that the perceived performance might even be better.
Ideally, we wouldn’t have to animate the entire page but we could have total control to make more interesting transitions. Heck, I was doing that a decade ago with a page for a musician where clicking around the site just moved things around so that the audio would keep playing (and it was fun).
This would be a great place for the web platform to step in. I remember Jake pushed for this years ago, but I’m not sure if that went anywhere. Then we got portals which are… ok? Those are like if you load an iframe on the page and then animate it to take over the whole page (and update the URL). Not much animation nuance possible there, but you could certainly swipe some pages around or fade them in and out (hey here’s another one: Highway), like jQuery Mobile did back in ancient times.
Chromium is working on something for that: Shared Element Transitions.
https://github.com/vmpstr/shared-element-transitions/blob/main/README.md
Available in Canary to play with, although it’s only partially implemented right now.
I’ve been playing around with page transition lately. I’ve got a pretty good setup using and extending readyState for page enter. onBeforeUnload was a bit too limited for page exit so I ended up using events on links.
I won’t post a link here but if someone is interested you can always send me a pm I guess.
I’m interested, can’t find how to PM you. You can find me in github as tomyo. Thanks!
it’s always better to not waste users’ time with blocking animations
Feels dogmatic.
Sometimes animations help users understand what is happening more clearly.
Animation can actually be used to increase accessibility by explaining context.
Whenever a user goes, “Wait, what just happened?”, they’re expressing confusion over a transition from one state of the UI to another. That’s why operating system UIs animate almost everything by default, especially Android and iOS.
That being said, it’s typically best to limit animations to 300 milliseconds at most, and acknowledge if the user has “prefers-reduced-motion” toggled.
It could still be the case that the first few times a user interacts with your interface, you’re explaining the context, but in the next 1000 times they use it, you’re slowing them down. I suspect this is why popular apps (like Facebook/Instagram) have very few transitions/animations.
That is one thing I love about Svelte-Sapper now Sveltekit is component transition! Its so awesome
Yes. Was going to say this. This is a good built in feature of Svelte-Sapier
Totally. And with Kit you can route things on the front end so it looks and feels like a full website, just way faster. Not to mention you can SSR for the first load. Best of both worlds.
I have been building just that, a platform that uses JSON directed dynamic function branching in its architecture. It is a single page social media post site, that can produce url versions of shareable content. It also animates-in, individual sections with many custom built animation effects, from sequential staircase rotations to scale-in fade-in to a host of the coolest animations I could find in the past 6 years. It’s also going to have a cms, that makes creating new buttons and content a breeze. The platform will be hosted online, and with a few clicks and using your purchased domain name it’ll automatically install a customiseable version of the social media post site, and also automatically create an android app to accompany your new site. It also has auto-sizing css, and works on every device that has a browser or is android, except the iphone so far. There are customiseable themes available, and it allows users to search the net in its own iframe browser, which automatically detects content types and puts them to use. My name is Jonathon, and my email is [email protected] if you’d like to know more.
I guess the challenge with implementing some standard of doing this, is that it would only happen on page unloads really. You wouldn’t be able to efficiently load resources and apply a page transition into a page because you’d need to have the transition already loaded.
Me, too. Portals looked far more powerful than you describe to me, but I haven’t hacked with them, just viewed demos. Odd, though… Did you see the one where the portal followed the mouse and you could click anywhere and spawn portals? I forget where I saw it.
If you’re going to create animated transitions between pages, it’s important that the application should work the same way (apart from the animations) as a normal webpage does. In particular, in a normal web application, browsers remember the scroll position of pages as you navigate through history, but doing this in an SPA is tricky and you have to resort to all kinds of hacks to store the scroll position. I don’t see anything good about having a nice animation effect in some best-case scenarios but then the page doesn’t work in an expected way in others.
Things are looking up:
https://github.com/WICG/shared-element-transitions/
(Only single page apps for now, but fingers crossed that this gets applied to pages too.)