Interesting. As it stands now, all my apps in the wild use a single JS lib I wrote years ago for view transitions ("screen" transitions) - which essentially bu

Interesting. As it stands now, all my apps in the wild use a single JS lib I wrote years ago for view transitions ("screen" transitions) - which essentially builds the next screen off the side of the page with a series of async calls, and once it's built without errors, swaps CSS classes with the main screen (each having a simple CSS animation to slide in or slide out). This has the benefit of allowing a screen change to abort if the user is suddenly offline or doesn't have access to the screen they're trying to load, or something like that. Additionally, the thing writes into the browser history if you want it to, and remembers which direction it swapped the screen in from. I'm not sure how logic like this would be addressed with the new view-transition-* syntax; maybe it's really just meant to replace the types of "-in" and "-out" animations I've been using on full-screen holders. I'll be interested to play with it.