Is this something that (in theory) could be improved and customized with view transitions?

Yea. We need a new opt-in to do a same-document ViewTransition for the fullscreen case. Authors can't do it using the document.startViewTransition API since that needs to be called before the DOM change. And by the time the author is notified of the fullscreen event, it's already too late.

There's also the problem that we currently abort transitions if the "snapshot containing block" size changes here. Instead likely the cached transforms need to be adjusted so the elements stay-in-place when the viewport size changes.

@nt1m @noamr @vmpstr

Is this something that (in theory) could be improved and customized with view transitions?

Nice idea!

Yea. We need a new opt-in to do a same-document ViewTransition for the fullscreen case. Authors can't do it using the document.startViewTransition API since that needs to be called before the DOM change. And by the time the author is notified of the fullscreen event, it's already too late.

Why not?
document.startViewTransition(() => element.requestFullscreen())

There's also the problem that we currently abort transitions if the "snapshot containing block" size changes here. Instead likely the cached transforms need to be adjusted so the elements stay-in-place when the viewport size changes.

Note that an element becomes full-screen, not a document. Perhaps this would work better with element-scoped transitions? I think we can find a way to deal with the changes SCB.

@nt1m @noamr @vmpstr

Not super enthusiastic of giving up UA control of this transition, especially given different platforms may have different ideas how fullscreen works.

Why not? document.startViewTransition(() => element.requestFullscreen())

requestFullscreen() is async. It's not necessary that the next frame after the update callback runs is a fullscreen frame. There's also the fact that exiting fullscreen can be triggered using browser/OS UI.

I think we can find a way to deal with the changes SCB.

+1. We have to for most use-cases of element-scoped transitions. Just wanted to point that this is also a dependency.

Not super enthusiastic of giving up UA control of this transition, especially given different platforms may have different ideas how fullscreen works.

Happy to hear the details on the kind of control you think the UA should keep. We have heard this feature request from other developers as well, being able to animate elements when the layout changes is helpful in re-orienting users.