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 👍🏼

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

god i miss your videos

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.

Isn’t that exactly what was done?

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?!

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!

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)

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.

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.

Thank you

CSS animation is independent except via class name, I don't think that would be easy

Printing this and mailing it to Paul

Exactly! We needed true cross-fades for this, so we standardised that separately