In case you can't tell, I'm really excited about this feature, but I want to make sure we get it right. Please ask any questions you have, and I'll answer them here. Comments are also welcome on the repo linked in the description.
The late, not-really-seen-by-anyone-else-as-great element allowed this sort of use (although the Page Transitions API is a lot more helpful about it than was, which mostly gave you the ability to build it yourself!), but the other thing that gave developers was access to both the before page and the after page at the same time. You could use portal.activate and pass data along with it which could be received by the next page, in essence giving a way to add arbitrary extra data to a page navigation. For an SPA you don't need this (because you're all one page), but it's hard for normal websites with more than one page, and portal helped with that. (The hacky ways to do it, like sticking things in the query string or localStorage, aren't as nice, and you can't postMessage from before to after because before and after aren't both present at the same time). Is there anything that the Page Transitions (or maybe the page navigation?) API does to help with that? (this stuff is super duper cool, btw.)
@@StuartLangridge isn't dead, it's just resting. No, seriously, it isn't dead, it's still being thought of for that page-in-page stuff. It was delayed by the infrastructure work needed for putting a 'top level' frame within another page, which is needed for portals but also prerender.
Thanks for the great video, Jake! It's not only exciting stuff, but the presentation is also very well thought out (and funny ;-) Can you see this in action anywhere, e.g. using Chrome Canary for Android? (Not sure if I missed something)
This is gonna be big! 9:43 is when my heart was literally jumping with joy like a small kid! I've been waiting for this for years. Please make this main stream soon. This has so much potential.
@@REAZNx you are so smart lets ship 5mb of js to the client to make a buggy mess from 2007. Also it needs react on top so it doesnt work with better frameworks like sveltekit.
The beauty is that you can implement the feature right away, using a fallback for browsers that don't support the feature, and then simply wait until they all support it.
@@sillvvasensei This is true, however I'd be worried about maintenance. Whenever we want to add or change a new transition, we would have to do it twice in different ways if we want to have similar experiences.
Imo at this point you aren't making a series of webpages, you're making web apps. I feel like the idea of these relatively complex applications being treated as web pages is an archaic and limiting abstraction that sort of limits what the web can be. This is oddly coming from someone who dislikes web apps, so I'm not just hating on web-based progress.
Finally lol it only took 10+ years but finally we here!!! This has been one of those features I've always wanted. 1. browser transitions (check) 2. css variables (check) 3. nested css (on hold)
Brilliant! This is one of the most exciting topics for me in I/O 2022. It must have taken tons of hard work to make it look as simple as a breeze. Thanks for making web better!
This is amazing and the API is extremely clever. Currently making animations in SPA is extremely difficult. And the cleverness of this API makes it even possible to work in traditional multi page apps and this makes me even more exited because I'm mainly a backend dev
Very cool! I implemented page transitions using JavaScript and CSS and it was pretty complex. I had to pre-load the content in the background, create the layout out of view, and then do the choreography. The "zoom in" transitions as seen at 9:40 are especially tough. This is a much simpler and more elegant solution. I hope that you make it generally available soon, and that other browsers follow suit. Good work!
I was skeptical, as I have built most of those transitions animations myself in various Apps, which is really not fun. This looks like a well thought out and flexible API - thats awesome!
We've presented parts to the CSS working group, and folks have been supportive. But we don't have a real spec yet, so it's too early to ask other browsers to commit.
@@mathe42 absolutely. Me too. I like how easy the fallback is, as well. However, I think it won’t be widely used until the feature is adopted in the big frameworks, Angular, Vue, Nextjs, etc. And for that the api needs to be somewhat stable and widespread.
@@justsaying4471 i think it will be adapted very quickly as animation libraries uses the same pattern already for this type of page transistion. eg framer motion.
Man I love this. Until other browsers adopt it, I can see creating scenario-specific web apps for kiosks and such. Just awesome. Is Canary available on iPadOS?!
"I dont know, You could probably do something better." Now THIS is how you get people into it, An Instructor who has enough confidence to encourage the students.
Thank you. I've been a vanilla html+js+css type of person because I didn't want to add the project complexity and learning required for anything extra. When this becomes standard, it will have proved that it was worth the wait.
This is really exciting - I love that it reuses lots of existing web building blocks and APIs so you don't need to learn much new syntax and just use existing knowledge 😍
I think it would be great to define the root element so for example you have some div in your page and a transition can be created only for the content inside. The rest of the page would be interactive while the transition runs.
That's how this ought to have been done, but they are too comfy and a bit lazy at Google, i am sorry for being negative but it's true. If it was some people engineers grinding out there, with the power they have to implement such features, they would've made it properly.
Totally! I was wondering about using this API with PWA features and having the possibility to deploy to Google Store, this would make it possible to write SPAs that could become very convincing native apps!
Subtle transition animation greatly helps usability by providing informative visual queues, but when transition animations take too long to complete, they start to distract and create headaches. Human eyes will want to tack any movement. When the movement speed is above a certain threshold, our eyes will give up tracking during the the transition animation and then eventually snap on the final state of the animation when it stops. This is far better than a slow transition animation where our eyes try to track the whole animation and suffers disorientation and headaches and eye strains. More is not necessary better. A good UI animation should not attract attention to itself.
This is great. I’ve witnessed firsthand while writing react-motion-router how difficult this all is. It seems simple conceptually but when you layer desirable features on top of each other it starts falling apart and introduces weird edge cases. In my case I was animating the live DOM for each page (as I was unaware of a way to screenshot the current state) which wasn’t great. One question I have is why contain: paint?
From MDN: > The contain CSS property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits. In case of these page-transitions it tells the browser to not need to paint the transitioning elements that are offscreen. In this case, elements which transition left and right outside the screen.
This concept of "Page transistion" reminded me of NextJs; as it has the "shared Layout" conectto which is not reloaded during navigation (eg. header and footer) and in which the pages are injected without reloading. Not having to reload allows you to apply page transitions.
That explains why Jake made an entire HTTP 203 episode about cross-fade! 😉 Looks great! I'm looking forward to use it! I love how easy it is to customize using good old CSS!
This is genius! Have been working with @framer/motion with layout transitions and this is almost alike! Does this also enable on-page automatic FLIP animations that scales, resizes etc and automatically resolves the animation?
Right now it acts over the whole page, so it might not be appropriate for things when only happen in part of the page (but maybe it's fine in a lot of cases). There's already a github issue open to explore this where the effect is rooted to a smaller area of the page.
@@jakearchibald that would be very helpful, e.g. in case the next “page” opens in a modal while the previous page stays visible in the background (example, opening a Trello card or photo from a gallery)
5:12 ah yes the start of "ToDo / to be fixed" comments in the code Love the attention to detail throughout the whole video, it's just something most apps lacks nowadays.
I'm definitely going to be playing with this. Just launching my agencies new website and the page transitions from other Frameworks were a nightmare to mix in with smooth scrolling and gsap, so I left it for version 1.1. Something like this could be the future 💪
This looks great! Being able to encapsulate targets as images will make things a lot more supportive. How does it combine with WAAPI or other JS animations? It would be great to target this stuff with spring animations, independent x/y transitions etc.
Is there a way to control when the "incoming image" is captured? For example, a page with a lot of images may take quite some time to load, but the part of the page that's above the fold will load much faster and that's the only part that's needed in order to capture the incoming image.
I am weeping with joy here.... What didn't I try... Gsap Anime js Animate.css Hover.css And nothing worked and i gave up... Finally i now have a hope of seeing the following Multiple elements of a dynamic SPA load with smooth and fluent animation that gives the page a sense of continuity... A sense of direction in the chaotic Internet.
Sweet. Perfect Progressive Enhancement where you just take something that already works and make it look nicer for some. But as a non-SPA user I'll wait for the upcoming MPA info
In case you can't tell, I'm really excited about this feature, but I want to make sure we get it right. Please ask any questions you have, and I'll answer them here. Comments are also welcome on the repo linked in the description.
The late, not-really-seen-by-anyone-else-as-great element allowed this sort of use (although the Page Transitions API is a lot more helpful about it than was, which mostly gave you the ability to build it yourself!), but the other thing that gave developers was access to both the before page and the after page at the same time. You could use portal.activate and pass data along with it which could be received by the next page, in essence giving a way to add arbitrary extra data to a page navigation. For an SPA you don't need this (because you're all one page), but it's hard for normal websites with more than one page, and portal helped with that. (The hacky ways to do it, like sticking things in the query string or localStorage, aren't as nice, and you can't postMessage from before to after because before and after aren't both present at the same time). Is there anything that the Page Transitions (or maybe the page navigation?) API does to help with that?
(this stuff is super duper cool, btw.)
@@StuartLangridge isn't dead, it's just resting. No, seriously, it isn't dead, it's still being thought of for that page-in-page stuff. It was delayed by the infrastructure work needed for putting a 'top level' frame within another page, which is needed for portals but also prerender.
Thanks for the great video, Jake! It's not only exciting stuff, but the presentation is also very well thought out (and funny ;-)
Can you see this in action anywhere, e.g. using Chrome Canary for Android? (Not sure if I missed something)
@@Rachoszsky yep, see the description for links! Particularly the developer guide
@@jakearchibald Thanks! Awesome to see this in action, one step closer to that native app feeling 👍🏼
This is gonna be big! 9:43 is when my heart was literally jumping with joy like a small kid! I've been waiting for this for years. Please make this main stream soon. This has so much potential.
hahahah same 100%
Have you never heard of Framer Motion before?
@@REAZNx you are so smart lets ship 5mb of js to the client to make a buggy mess from 2007. Also it needs react on top so it doesnt work with better frameworks like sveltekit.
@@PanosPitsi Framer is 4kb but ok.
This is amazing. Excited to be able to use it in PWAs, and get that much closer to native feel.
god i miss your videos
Lovely!! Been thinking a lot about page transitions recently, so the timing here is perfect. This is a great intro to the new APIs
Can't wait to use this in 4 years when Apple implements it in Safari!
The beauty is that you can implement the feature right away, using a fallback for browsers that don't support the feature, and then simply wait until they all support it.
@@sillvvasensei absolutely. But iOS users not experiencing these lovely transitions is a large chunk of your intended audience I’m sure.
@@sillvvasensei This is true, however I'd be worried about maintenance. Whenever we want to add or change a new transition, we would have to do it twice in different ways if we want to have similar experiences.
Imo at this point you aren't making a series of webpages, you're making web apps. I feel like the idea of these relatively complex applications being treated as web pages is an archaic and limiting abstraction that sort of limits what the web can be.
This is oddly coming from someone who dislikes web apps, so I'm not just hating on web-based progress.
XD lmao
Finally lol it only took 10+ years but finally we here!!! This has been one of those features I've always wanted.
1. browser transitions (check)
2. css variables (check)
3. nested css (on hold)
I'd love for this to be discussed with other vendors and added as a cross-browser standard.
Great job guys, it looks amazing.
Isn’t that exactly what was done?
We love you Jake! You're incredible and thanks to the team for all the work on this api!
Love this guys mannerisms, feels so candid and authentic not like a scripted advert or kids TV show like some Google dev vids
Brilliant! This is one of the most exciting topics for me in I/O 2022.
It must have taken tons of hard work to make it look as simple as a breeze.
Thanks for making web better!
This is amazing and the API is extremely clever. Currently making animations in SPA is extremely difficult. And the cleverness of this API makes it even possible to work in traditional multi page apps and this makes me even more exited because I'm mainly a backend dev
I absolutely love this feature and the simplicity behind it! Looking forward to try it out
This is so exciting. Probably my biggest wish for the future of the web. I'm really happy to see all the changes since v1 last year.
This is awesome! I really hope this gets widely adopted so we can use it across browsers. That'd be a dream!
Very cool! I implemented page transitions using JavaScript and CSS and it was pretty complex. I had to pre-load the content in the background, create the layout out of view, and then do the choreography. The "zoom in" transitions as seen at 9:40 are especially tough. This is a much simpler and more elegant solution. I hope that you make it generally available soon, and that other browsers follow suit. Good work!
My absolute favourite element of all of this is a single word: Customisability. I live by this principle, and I'm glad to see I'm not alone
I was skeptical, as I have built most of those transitions animations myself in various Apps, which is really not fun. This looks like a well thought out and flexible API - thats awesome!
I have been waiting ages for page transitions for web apps at last I can't wait to get my hands on it. Thanks guys!
The API seems so simple and well designed ! Can't wait to start poking at it !
Wow, this is cool. I like the simplicity of the api. That’s its real strength, I believe. Any news on whether other browsers will support it as well?
We've presented parts to the CSS working group, and folks have been supportive. But we don't have a real spec yet, so it's too early to ask other browsers to commit.
Even If this only lands in Chrome I will use it!
@@mathe42 absolutely. Me too. I like how easy the fallback is, as well. However, I think it won’t be widely used until the feature is adopted in the big frameworks, Angular, Vue, Nextjs, etc. And for that the api needs to be somewhat stable and widespread.
@@justsaying4471 i think it will be adapted very quickly as animation libraries uses the same pattern already for this type of page transistion. eg framer motion.
Man I love this. Until other browsers adopt it, I can see creating scenario-specific web apps for kiosks and such. Just awesome.
Is Canary available on iPadOS?!
"I dont know, You could probably do something better." Now THIS is how you get people into it, An Instructor who has enough confidence to encourage the students.
Thank you. I've been a vanilla html+js+css type of person because I didn't want to add the project complexity and learning required for anything extra. When this becomes standard, it will have proved that it was worth the wait.
I had been waiting so long for this!!!
8:19 responsive fade and slide transitions are now called: The Archibald
Nice! Good job to the team!
Also impeccable presentation Jake! :)
You're actually using a Joycon as a clicker? Glad to find other people doing that!
So extremely cool, I have no word for it. Btw the production quality of this video is through the roof
This is the most exciting thing I've seen coming to the web in years!!!
Thank you and congratulations 👏👏
Man ! your talking skills are killing it ! just thank you for this 😁
This is really exciting - I love that it reuses lots of existing web building blocks and APIs so you don't need to learn much new syntax and just use existing knowledge 😍
Love the flexibility of tagging things with CSS, cool stuff!
So sad it's only coming now, but just as excited! Can't wait to be able to use it
Now, this is what I need in web apps. I can't wait for this to come to regular chrome!
This is SO cool. Amazing work from the whole team. Looks super easy to set up.
You guys at Google are absolute legends, wtf. Can't wait to play around with the new api ö_ö
Can't wait for designers to go crazy with page level animations now 🤩😍😀
This is crystal clear stuff - love the interactive examples, great work
9:42 Oh my gooood I dreamed of that for soooo loooong ! Finallyyyy!
I am incredibly exited for this
This guy needs to do all of Google's announcements from now on. Excellent communication.
Thank you
I think it would be great to define the root element so for example you have some div in your page and a transition can be created only for the content inside. The rest of the page would be interactive while the transition runs.
That's how this ought to have been done, but they are too comfy and a bit lazy at Google, i am sorry for being negative but it's true. If it was some people engineers grinding out there, with the power they have to implement such features, they would've made it properly.
Waiting patiently for this one! Its a good time to be a developer! Thanks to you and the team for this
Really really cool! Good to see some care with transitions.
Wow, that's a really game changer for SPAs and SPA-type websites. Now let's all hope, it'll become implemented soon 🤞
Totally! I was wondering about using this API with PWA features and having the possibility to deploy to Google Store, this would make it possible to write SPAs that could become very convincing native apps!
This guy is a fantastic presenter.
seeing jake without surma is absolutely heartrending
Bravo for making something complex simple. Looks great!
Wow, this is one hell of an amazing feature.
INSANE!! can't wait for it to roll out to the main build! Will totally give it a try ;)
Omg yeah, I really waited on this for a long time
This is fantastic! Love the thinking here and the control available in CSS. Can’t wait to embrace this in my websites!
Oh boy, I'm waiting for something like this for so long
It's really cool! I am excited to hear this news, what a big progress in web app experience!
Subtle transition animation greatly helps usability by providing informative visual queues, but when transition animations take too long to complete, they start to distract and create headaches.
Human eyes will want to tack any movement. When the movement speed is above a certain threshold, our eyes will give up tracking during the the transition animation and then eventually snap on the final state of the animation when it stops. This is far better than a slow transition animation where our eyes try to track the whole animation and suffers disorientation and headaches and eye strains.
More is not necessary better. A good UI animation should not attract attention to itself.
This is crazy. I'm excited about it!
This! This is exiting!
This is exactly what is missing UX wise on the web!
This is awesome and Jake is awesome give that man a raise
Printing this and mailing it to Paul
I can't wait for this!
this is what ive wanted for so long so long
Oh yeah, this is great. Simple and
yet customisable.
Powerful tool.
Omg my jaw hit the floor. I’m so excited for this to be out of canary 😍😍😍
Navigation API will be brilliant. Can't wait to play with it.
Nice concept Jake - thanks for sharing !
One who got the idea to add this is a real god
Amazing presentation of amazing new tech. I am excited!
This is great. I’ve witnessed firsthand while writing react-motion-router how difficult this all is. It seems simple conceptually but when you layer desirable features on top of each other it starts falling apart and introduces weird edge cases. In my case I was animating the live DOM for each page (as I was unaware of a way to screenshot the current state) which wasn’t great. One question I have is why contain: paint?
From MDN:
> The contain CSS property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits.
In case of these page-transitions it tells the browser to not need to paint the transitioning elements that are offscreen. In this case, elements which transition left and right outside the screen.
@@dealloc thank you so much for the explanation.
Amazing video! It was a pleasure to listen your presentation. And great feature, of course!
This is absolutely fantastic! And, as usual, awesome presentation Jake! 🍻
Absolutely gorgeous! I did the screenshot thing but it will be great to have native API.
This concept of "Page transistion" reminded me of NextJs; as it has the "shared Layout" conectto which is not reloaded during navigation (eg. header and footer) and in which the pages are injected without reloading. Not having to reload allows you to apply page transitions.
This is a super demonstration of an exciting API
Very exited about this feature! Great speaker too!
Super cool! Look forward to standardisation of this 👌
beautiful , this might be the next curve on web
This is an amazing idea, and I'm looking forward to what can be achieved with this pattern
i also wanted this feature for years, pwa are looking so natural 🔜!
This is insane ! Mashallah ! I like how the web is evolving very fast year after year.
Give this man a channel
This is so good, I wanted this for so long
I hope this api is gonna be suported by all browsers in the near future, because i'll be using it a lot!
That explains why Jake made an entire HTTP 203 episode about cross-fade! 😉
Looks great! I'm looking forward to use it! I love how easy it is to customize using good old CSS!
Exactly! We needed true cross-fades for this, so we standardised that separately
This is genius! Have been working with @framer/motion with layout transitions and this is almost alike! Does this also enable on-page automatic FLIP animations that scales, resizes etc and automatically resolves the animation?
Right now it acts over the whole page, so it might not be appropriate for things when only happen in part of the page (but maybe it's fine in a lot of cases). There's already a github issue open to explore this where the effect is rooted to a smaller area of the page.
@@jakearchibald that would be very helpful, e.g. in case the next “page” opens in a modal while the previous page stays visible in the background (example, opening a Trello card or photo from a gallery)
Did I just see DGD on a google dev video. What the? Someone at google has legit music taste.
this is going to be huge!!
This is looking quite awesome!
5:12 ah yes the start of "ToDo / to be fixed" comments in the code
Love the attention to detail throughout the whole video, it's just something most apps lacks nowadays.
This is so beautifully done 💖 THANKS JAKE
Really cool, hope it is supported well across browsers.
The whole video: it's so interesting, looking forward to use the APIs
at 9:43 ... whaaaaaaa I want them now!
This looks fantastic! Soooo much potential
This is a major change!
Damn, this looks pretty amazing! Hope this catches attention :O
Good. Now we can expect safari to have this in 6-7 business years
I'm definitely going to be playing with this. Just launching my agencies new website and the page transitions from other Frameworks were a nightmare to mix in with smooth scrolling and gsap, so I left it for version 1.1. Something like this could be the future 💪
This looks great! Being able to encapsulate targets as images will make things a lot more supportive. How does it combine with WAAPI or other JS animations? It would be great to target this stuff with spring animations, independent x/y transitions etc.
CSS animation is independent except via class name, I don't think that would be easy
This guy is super entertaining
Is there a way to control when the "incoming image" is captured?
For example, a page with a lot of images may take quite some time to load, but the part of the page that's above the fold will load much faster and that's the only part that's needed in order to capture the incoming image.
you can possibly use the Document.readyState property to determine if a web page is taking too long to load and override the transition if you may
Right or if we can just set it to a static image. Such as from a dataset of prerendered screens across device types and browser combos.
@@TheNewton That would defeat the purpose of a transition, which is to gradually transit to the actual next page and not a mock-up of the page.
I am weeping with joy here.... What didn't I try...
Gsap
Anime js
Animate.css
Hover.css
And nothing worked and i gave up... Finally i now have a hope of seeing the following
Multiple elements of a dynamic SPA load with smooth and fluent animation that gives the page a sense of continuity... A sense of direction in the chaotic Internet.
Excited for this API
Sweet. Perfect Progressive Enhancement where you just take something that already works and make it look nicer for some. But as a non-SPA user I'll wait for the upcoming MPA info