|View this newsletter on the web.
[Robin]: This week I’ve been thinking about page transitions on the web and this post from Chris earlier this year:
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.
Why should we animate pages like this? Isn’t that just a nifty trick and that’s it? Well, it is more complicated than that in this blogger’s opinion, because I think full-page animations are really useful to indicate where you are in the UI.
Here’s an example I think of a lot: when you select something to watch in the HBO Max app for iOS, the whole UI animates to the right and deep down in my bones this feels wrong. Because now all of a sudden that menu (in my mental model of this app) is now off to the right. But it should be off to the left of my screen because when I click the back button I want to swipe this whole UI back to where I just was, sort of like a carousel.
(This rant should’ve been saved for my therapist, huh?)
My point here is that page transitions aren’t only cool kickflips that we can pull off as developers to impress our friends, but they also give users spatial cues about where they currently are in the UI. Bad animations make us disoriented and feel a bit lost, whereas good page animations make you feel confident and focused.
Doing this sort of thing on the web is pretty tricky though but there’s a new proposal called the Shared Element Transitions API which gives us “a high-level way to transition between page states.”
Jake Archibald explains:
When you navigate around apps on your phone, there’s usually some sort of transition, from a simple fade or slide from one screen to another, to more complex transitions that move different elements independently
Although, on the web, we don’t tend to get those kinds of effects. Creating a transition from one page to another after clicking a link is, well, impossible. But, it isn’t exactly easy within a single-page app either.
This new API is designed to make all those transitions much easier for single page apps. In the example below that Jake shares, the API is told which elements are shared across pages—in this case, that’s the header that sticks in place:
The really neat thing about all this, to me at least, isn’t this new fangled API but instead the way that the Chrome team is rolling this out. Because right now you can use this feature today in Chrome via an origin trial.
First, let me explain the problem. Today it’s kinda hard for browser manufacturers to experiment with new features and get feedback from the community but it’s also difficult for them to do that without them shipping broken stuff that they then need to roll back. Origin trials are the Chrome’s team solution to this problem.
The other problem is adoption: lots of us developers won’t even test stuff if it doesn’t have good browser support and we’re not going to build sites that require feature flags enabled in a particular browser. Here’s a great post from the Chrome team that explains all this:
The resulting situation is one in which features shipping on the web take a long time to design, and are then frozen into standards well before they have been significantly road-tested by real web developers.
And so with origin trials…
Once your origin has opted into a trial of an experimental feature you can then build demos and prototypes that your friends and beta testing users can try for the duration of the trial without them needing to flip special flags in Chrome.
This sounds like a great idea to me, but how do you use it?
Let’s say you want to experiment with this new transition API, well first you need to register for the trial and it’ll give you a code. You can then add that string to a
<meta> tag in the
<head> of your website.
And then… that’s it. Developers are told right up front that this origin trial will expire at a certain date, in this case on October 12, 2021. So the incentive here is to play with these features, but not to build your whole application around them because after a certain date they just won’t work anymore. But during this time, folks who use Chrome will have these features enabled for them.
From my perspective, this all seems like a great idea, except I suppose that these features won’t be tested in Safari or Firefox or any other browser for that matter. I guess I do have a tiny concern then that it feels a tiny bit like we’re building a web app for Google.
I look forward to all this drama unfolding next week!
(Editor’s note: he is absolutely not.)