[css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations

[khushalsagar]

View Transitions are currently limited to DOM changes within the same Document. We want to support these transitions for same-origin cross-document navigations. There are 2 proposed resolutions for this issue:

• Accepting the high-level algorithm outlined below which can be turned into concrete steps in a spec.
• Starting an L2 for the CSS View Transition spec for this feature.

The steps below describe the high-level algorithm. Links to issues which go into the details are included with the relevant step.

• Check whether this navigation type should allow a ViewTransition:

  • Check if the old Document has an opt-in to a ViewTransition. If not, return. Discussion for opt-in syntax is at 8048.

  • It’s unclear whether all navigations initiated via the browser UI should allow a ViewTransition. More discussion at 8783.

  • Should reloads run a ViewTransition? More discussion at 8784.

• Assuming the navigation type is allowed to do a ViewTransition, the browser waits until the following is settled:

  • The final URL, after server redirects, is known. This is because the transition needs to be limited to same-origin navigations. More discussion at 8684.

  • Whether the navigation will result in a change in Document is known. For example a 204 response could make the navigation a no-op. More discussion at 8782.

• Once the above is resolved, the following steps are run:

  • Dispatch an event, ViewTransitionBeforeCaptureEvent, on the old Document before any state is captured. This allows the author to decide which elements to tag based on the current Document state and the destination URL. More discussion at 8785. \ The timing of this event with respect to events on the new Document has to be clarified. An author may use this to pass contextual information about the old Document to the new Document. This information can influence what needs to be render-blocking on the new Document. More discussion at 8790.

  • Wait for the next rendering opportunity and execute “capture the old state” algorithm. This state is transferred to the new Document.

  • Set document’s transition suppressing rendering to true (prevent old Document from updating after snapshotting).

• It’s unclear if the navigation can be aborted after the above (the user hits the stop button?). If so, we simply resume rendering and discard the captured state.

• On the new Document, the following steps are run. It’s unclear whether these steps should run if the old Document didn’t opt-in to ViewTransitions. More discussion at 8791:

  • Dispatch an event which notifies the Document that a transition will be executed. This provides the author with the URL for the old Document and any contextual info from the old Document generated in ViewTransitionBeforeCaptureEvent. This info might be required to decide which resources should block the first render. For example, if there is a hero image which will be animated by the transition. Discussion on the exact syntax is at 8805.

  • Wait until all render-blocking resources have been fetched. This ensures we wait (up till a timeout) for the new Document’s resources. As per current spec, this waits at least until body is parsed. \ Render blocking currently only supports stylesheets and script elements. Syntax might need to be extended to cover images and the Document itself. \ We’d likely need an event for the author to know when render blocking is done. Different animations may be done based on whether a resource was fetched before first render. For example, cross-fading with new DOM element's image if it was fetched vs just the size/position animation with old DOM element's image if its still loading.

  • Before the first render, check if the new Document has an opt-in. If not, discard the captured state and return. This requires resolving style if the opt-in is in CSS. We could check it before the events but if the opt-in is in CSS the timing becomes tricky since we’ll need to resolve the style.

  • Execute the algorithm defined here to parse named elements in the new Document and generate pseudo-elements. \ The above requires running style/layout before the first lifecycle. It could cause redundant work if the author changes anything in the first rAF. Another option is to do this after running rAF, which is different than the SPA pattern.

Rest of the steps are the same as the SPA API. The approach above should be extendable to same-site navigations. Since there are more security/privacy implications to consider for same-site cases, it will be a follow up feature.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations, and agreed to the following:

• RESOLVED: Extend view transitions to cover cross-doc same-orig navigations

The full IRC log of that discussion

<bramus> khush: goal of issue is to start working on cross-document support for View Transitions
<bramus> khush: want to walk everyone to overall approach, to later turn in more concrete spec test
<bramus> khush: lot of details need to be sorted out
<bramus> khush: issue contains links to sub issues
<bramus> khush: also want to start an L2 of the spec for this feature, as its a fairly big thing
<bramus> Rossen_: makes sense, can we timebox to 5 minutes?
<bramus> Rossen_: dont want to deep dive in all subissues
<bramus> khush: i’ll try
<bramus> khush: ** goes over issue **
<bramus> khush: ** continues to go over issue **
<bramus> khush: ** still continues to go over issue **
<bramus> khush: ** still continues to go over issue (continued) **
<bramus> khush: that’s it
<bramus> khush: looking for feedback and resolution on L2
<bramus> Rossen_: do you have tag review?
<bramus> khush: yes, for same-document API. dont have explicit tag review for MPA, but want to get rough outline first and then present tag review
<bramus> Rossen_: please start tag review ASAP. is going to have a lot of discussion
<bramus> Rossen_: lots of security/privacy concerns will most likely arise
<bramus> Rossen_: you don’t need an ED, only an explainer
<bramus> khush: we are not targetting for cross-origin navs. explainer will make that explicit
<TabAtkins> Lot of details to nail down, but I'm very happy with th einitial work.
<bramus> Rossen_: any reasons not to continue this proposed outline?
<bramus> Rossen_: this is only a beginning
<bramus> Rossen_: any objections to cover cross-doc same-orig navs?
<bramus> Pro: Extend view transitions to cover cross-doc same-orig navigations
<bramus> RESOLVED: Extend view transitions to cover cross-doc same-orig navigations
<bramus> Rossen_: maybe in L1, though?
<Rossen_> ack fantasai
<bramus> khush: ** asks details on L1/L2 distinction **
<bramus> fantasai: ** spills the details **
<bramus> s/distinction/distinction and CR process/
<bramus> khush: thanks

[khushalsagar]

Nothing actionable on this issue.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations.

The full IRC log of that discussion

<vmpstr> scribenick: vmpstr
<vmpstr> noamr: i'm going to present and chat about view transitions
<vmpstr> noamr: we have a few VT issues scheduled for tomorrow. I feel like we deal with these issues like blind men and an elephant
<vmpstr> noamr: we're not seeing the big picture and what we're trying to do with it
<vmpstr> noamr: and some people might have not been here
<vmpstr> noamr: i want to show where we are and where we want to go, and start a syntax discuss that we can continue tomorrow, so everyone has context
<vmpstr> (presentation)
<vmpstr> noamr: i'll show what we have today, and plans for the future
<vmpstr> noamr: what is CSS view transitions (VT)
<vmpstr> noamr: it's a transition between states; before we had a transition between elements
<vmpstr> now we take a document capture it and morph it into a new state
<vmpstr> noamr: we do this by capturing an element snapshot, change the dom, capture a different set and morph by name
<vmpstr> noamr: this is a general idea of VT
<vmpstr> (demo)
<vmpstr> noamr: here there's switching immediate. But if we put it inside start view transition, they get immediately a cross fade
<vmpstr> noamr: now, this is a default and building on this we can define a whole bunch of customizations
<vmpstr> noamr: i wanted to show something similar to what we saw
<vmpstr> noamr: we have a button that switches states
<vmpstr> (live demo!)
<vmpstr> noamr: it does it immediately, if we add startViewTransition to it, and put it in the startViewTransition block, it cross fades
<vmpstr> noamr: this is nice, but you want to customize
<vmpstr> noamr: so for example, I'm giving h1s transition name of heading
<vmpstr> noamr: and then I can customize the animation between heading elements
<vmpstr> noamr: so now the animation is 1 second and has a blur
<vmpstr> noamr: I do all of this with pseudo elements
<vmpstr> noamr: the power here is that there is not just pseudo elements for the states together, but separate: one for the old state and one for the new state
<vmpstr> noamr: i'm defining that there is a slide but one of them is a reverse
<vmpstr> (this is still live demo)
<vmpstr> noamr: this is extremely customizable, there's something at the start and at the end, and pseudo elements to transfer between states
<vmpstr> noamr: this is css VT today in terms of features
<vmpstr> (back to preso)
<vmpstr> noamr: it creates a morph by creating a tree of pseudo elements with names like heading in this case
<vmpstr> noamr: it creates a group for the transition, and a pair of elements old and new for the states
<vmpstr> noamr: people are excited about this, there are a few companies using this and frameworks (missed the names)
<vmpstr> noamr: it's been a quite a popular request on surveys
<vmpstr> noamr: i want to jump from that to what we saw people do
<emeyer> s/missed the names/Svelte.kit, Astro/
<vmpstr> noamr: one thing that is very popular is a full page style, you set the page, you set the transition, you go to a different page
<vmpstr> noamr: you have one animating element that is root. Before the css VT you had to put both pages in the dom and use a transition group
<vmpstr> noamr: a11y wise it was where both states are in the DOM. Here there is no dom, it's pseudo elements and style
<vmpstr> noamr: this is a very common use case
<vmpstr> noamr: this is an even commoner use case. here is a list of songs, and you click one and expands to one song
<vmpstr> noamr: this is a list to details view, like shopping list to details
<vmpstr> noamr: this is extremely popular in demos that we have seen
<vmpstr> noamr: the third one is different: it's animated layout, you can put stuff in a grid or a list, give everything view transition names, and change their placement in the grid
<vmpstr> noamr: and this animates it
<vmpstr> noamr: this is less of a navigation, but something internal to the page. we see this in things like timeline where list changes order
<vmpstr> noamr: automatically sorting list is something we see a lot, and it's something i'm excited about
<vmpstr> noamr: it was not easy to do before, you had to create some ghost elements with transforms. it was not fun, depending on what fun is for you
<vmpstr> noamr: the constraints of css VT, where we are today, what you say looks demo-y
<vmpstr> noamr: it can be incorporated into a page, but it's limited to the document
<vmpstr> noamr: everything in the document you have, it will be selected for the document
<vmpstr> noamr: also the whole document freezes, maybe you want just a widget to animate, and you don't want the whole page to lose pointer events etc
<vmpstr> noamr: and you saw that a lot of cases are navigation cases, but if you leave the document, then you lose the transition. You don't have a CSS state today that is cross ocuent
<vmpstr> noamr: from this we derived what we want in the vision; we want to remove constraints
<vmpstr> noamr: to explain what we want to do, i want to show an ugly wireframe of a music list
<vmpstr> (demo slide)
<vmpstr> noamr: what you want on this page is three different transitions
<vmpstr> noamr: first you want the slide page thing, you want the nav bar where things slide on the next page
<vmpstr> noamr: then, if you click on a song, you want the song to expand
<vmpstr> noamr: the third if you drag and drop the list, you want the list to animate
<vmpstr> noamr: it doesn't look like an uncommon use case for a real web app
<vmpstr> noamr: when using VT myself, i was struggling with doing this: incroproate a bunch of things into the same app
<vmpstr> noamr: this is not in priority order, but this is what we envision for VT
<vmpstr> noamr: we think that we want to allow to scope element transitions to elements
<vmpstr> noamr: second, semantically group: you have the same app with different grouping of animations. you have the slide animation and expand animation and you group all elements that particpate in the animation semantically
<vmpstr> noamr: number three, we want the transition to be triggered by a cross document navigation. we want transitions to work in the MPA. we definitely don't want view transitions to be a deciding factor for why people pick SPA
<vmpstr> noamr: we want it to work with javascript and without javascript
<vmpstr> noamr: element scoped transitions, and btw, all those three things is not because we're planning on doing them all in one go, but just when we design each one, we want to consider everything
<vmpstr> noamr: we don't want to spec ourselves into a corner
<vmpstr> noamr: element scoped transitions is about animating a widget without stopping the whole page, so animate with drag and drop while the page is responsive
<vmpstr> noamr: can't do this today, but want to do it in the future
<vmpstr> noamr: this is sort of how you do it in javascript
<vmpstr> noamr: so currently the document.startViewTransition function exist. We want to have something like playerWidget.startViewTransition
<vmpstr> noamr: and all those pseudo elements you saw, instead of being just on the html element, any element can be the originating element: #playerWidget::view-transition-group(play-pause)
<vmpstr> noamr: and all animations are scoped to that
<vmpstr> noamr: you might have simultanious (sp) transitions running at the same time
<vmpstr> emilio: i wanted to ask about group. for top level VT in SPA
<vmpstr> emilio: view transition are fixpos / top layer, what is the rendering model for the scoped transition. A thing with view transition name would need a containing block etc
<vmpstr> khush: this is one of the things that we need to sketch out, like what constraints it needs. but what you saw on the previous slide, but what you saw before would happen in the iframe
<vmpstr> emilio: the iframe is a whole contained thing
<vmpstr> khush: the idea is to bring that type of containment into one element
<vmpstr> noamr: a lot isn't solved
<vmpstr> ntim: how does it work if you have a element that overlaps the scope, and you put it so it overlaps
<vmpstr> ntim: if you have your scope, and an element outside the scope, how does the screenshotting work
<vmpstr> noamr: the capture is of elements, not the screen and the overlap doesn't change
<vmpstr> yoav: so if there's occlusion, that doesn't change anything
<vmpstr> noamr: so you capture an element as an element capture, not the occluded screen capture
<vmpstr> noamr: with rendering and implementation for scoped element transitions, we'll have some challenges, but whenever we design the syntax for thing, we consider that the VT will not always be global
<vmpstr> noamr: semantic grouping, defining multiple transitions, but activating just one of them
<vmpstr> noamr: when we click a nav bar, it does slide, but when you click an element it expands
<vmpstr> noamr: these would be different animations, different pseudo elements, etc
<vmpstr> noamr: a lot of people struggle with this, because they define too many names, and overdefine things, or things work slowly because they have a bunch of elements
<vmpstr> noamr: we capture things that don't transition so you transition things that don't need to transition
<vmpstr> noamr: i've seen this from demos and that's something that we can fix and want to fix
<vmpstr> noamr: how do you fix it today? you can do it in javascript, say you want to click on details to expand
<vmpstr> noamr: you can set a class on <html> then run the transition and then remove the class
<vmpstr> noamr: during the transition you know which transition ran, so when you're in the expand song class, you know what names exist
<vmpstr> noamr: instead we're suggesting when you startViewTransition you pass a list of ephemeral classes
<vmpstr> noamr: this is the css of how you would read these classes
<vmpstr> noamr: btw this is all bikeshed
<vmpstr> noamr: we thought about this a lot, but this is all bikesheddable
<vmpstr> emilio: one thing that jumps at me when i see that is that the way you do that means that you need to restyle the page
<vmpstr> emilio: and you can change a lot more than the view transition names
<vmpstr> trying again
<vmpstr> "connecting to network"
<vmpstr> conversation is about making a selector vs qualifying the names
<vmpstr> noamr: doing something with a name is a possibility we felt it was a bit limiting
<vmpstr> emilio: in particular for MPA, you're about to nav away from the page, I'd rather avoid doing actual work that will do render
<vmpstr> noamr: you need to do render into a capture, and you have something with view transition name, but you don't want the text to appear
<vmpstr> emilio: i'm still sad about things that require layout
<vmpstr> noamr: sure we can reason about doing this at the last moment
<vmpstr> noamr: but it's a drop in replacement for the html class name, but it's a good point, maybe we're allowing a lot of last minute things for MPA, but it's up the developers
<vmpstr> emilio: sure
<vmpstr> michael: is this ore about starting a subset of possible transition or customizing transitions or both
<vmpstr> noamr: both
<vmpstr> michael: once started the set will be on the whole document, the latter will allow multiple transitions
<vmpstr> khush: if your transition targets a whole document, but have multiple transitions
<vmpstr> noamr: this is 100% syntactic sugar, and continuation of previous CSSWG F2F, if something starts with style and ends with style, it shouldn't change the dom
<vmpstr> noamr: I think fantasai brought it up and it resonated with me
<fantasai> s/shouldn't/shouldn't be required to/
<vmpstr> noamr: if we decide to not do this, i'm ok with that too
<vmpstr> noamr: we have a type of the transition, and a slide one, and reason about them separately
<vmpstr> noamr: the reason we put it in the pseudo class because of hte previous thing about scoped element transitions
<vmpstr> noamr: the active view transition pseudo element can go into element that is a view transition route
<vmpstr> noamr: the third one and most improtant one is navigation triggered transition -- automatically start a transition when a document navigation takes places
<vmpstr> noamr: (missed)
<vmpstr> noamr: let's say we have the same app, and we have slide transitions and the song expands
<vmpstr> noamr: we want the song to be in a different document
<vmpstr> (reconnecting)
<vmpstr> noamr: we've been working with modern frameworks like nextjs, you don't build your app as MPA or SPA, you just build your app
<vmpstr> noamr: and sometimes the choice is done did your document load, did you pass hydration to make it an spa
<vmpstr> noamr: so when I think about an SPA or an MPA, i want to think about it as a detail
<vmpstr> noamr: it's a progressive enhancement between different cases
<vmpstr> noamr: they don't want to rewrite their css for different cases, so it should be more infrastructure
<vmpstr> noamr: so we want the song to expand whether it's the same document or cross document and work consistently
<vmpstr> noamr: plus we don't want to break the sort transition while we do that
<vmpstr> noamr: so again, reminding of the bikeshed icon
<vmpstr> noamr: so we define something like an event or behavior that is bidirection
<vmpstr> noamr: we say if we're in the same origin navigation it's to trigger them rather than not trigger, can be called enable disable or what not
<vmpstr> noamr: the concept is you put this in css document in both documents
<vmpstr> noamr: and both sides opt in to trigger a transition
<vmpstr> noamr: we'd read it twice: right before the last frame of the old document, and before the first frame of the new document
<vmpstr> noamr: this also applies to back/forward cache and prerender
<vmpstr> noamr: we'd read the current value of this and decide whether to trigger or skip the transition
<vmpstr> noamr: we also need js events or something to customize the transition, probably on both sides
<vmpstr> noamr: there is conversation with whatwg html spec to see if we can reach something
<vmpstr> noamr: but the idea is to have an event. the big use case is to have a new document that wants to use web animations not css
<vmpstr> noamr: then you get an event on the new document that can do that
<vmpstr> yoav: how is commit navigation be different in terms of negative side effects of unload
<vmpstr> noamr: we need to think about this, i'm hesitant to do this in unload event
<vmpstr> yoav: ok
<vmpstr> noamr: it has different htings that are different, and alternative proposals. one is it's only same origin navigation, so you'd be in the same javascript loop.. you're in the app
<vmpstr> noamr: the other alternative is to send a same origin redirect
<vmpstr> noamr: so you get a navigation event for navigation API, and get a redirect event if it redirects
<vmpstr> yoav: is it make it to be passive, or do we need to fire in the context of the old document
<vmpstr> noamr: it needs to request a frame of the old document and render into capture
<vmpstr> khush: one thing when we say the last frame is captured we need to define what your last frame, so we defer it until you have a navigation response
<vmpstr> khush: we are going to run a raf cycle and we tell the user this is the frame that will be captured, do your set up
<vmpstr> yoav: i' m not concerned about VT, but people using it for everything else. I want to maybe close down the event to be VT specific, but in the same way that we're limiting (missed) dismissal events
<vmpstr> yoav: it would be good to have preventive restrictions
<vmpstr> noamr: we want to be careful of people creating VT just to get this event, so i'm hesitant with artifical restrictions
<vmpstr> yoav: i'm not saying artificial, i'm saying you get the event, but you can't do fetch or beaconing, etc
<vmpstr> noamr: that's ok
<vmpstr> noamr: we want to be careful that is general, we don't want to say it's VT specific, because it can have an opposite effect
<vmpstr> khush: what i'm confused: every raf is going to need to be restricted? since raf will fire
<vmpstr> yoav: yeah, they'll queue raf and do weird things
<vmpstr> noamr: and people can do this in pagehide, we're adding an event before pagehide
<vmpstr> yoav: ok
<vmpstr> noamr: we have challenges with MPA VT, one is progressive rendering: the incoming page might not be loaded/parsed
<vmpstr> noamr: second is how do you deal with the lifecycle and events and footguns
<vmpstr> noamr: third one is in css: is navigation and event or a state, or you can say it's two events, because the state goes between two documents
<vmpstr> noamr: it's an event for the last frame and then for one more frame, so we're thinking more of it as an event than a state
<vmpstr> noamr: this is up for discussion
<vmpstr> noamr: this is also the first time where we define anything about navigations in css, so there was a fear of using a name like navigation for this
<vmpstr> noamr: this is about future proofing, maybe in the future we want to define something else here in the future, like regular keyframes that start on navigations
<vmpstr> noamr: maybe we want to qualify this with URLs or back/forward info
<vmpstr> noamr: so how do things work together, the three features we talked about
<vmpstr> noamr: first, you can start a view transition and give it a class
<vmpstr> noamr: if cross document wants to be semantically grouped, we can add @navigation and specify view-transition-classnames behavior rule
<vmpstr> noamr: now, our execution plan: we have two big issues we want to resolve soon
<vmpstr> noamr: first, global cross origin opt-in.
<vmpstr> noamr: second, the semantic grouping.
<vmpstr> noamr: i feel like if we have two those things, plus the html events, javascript style, and we resolve these two things in the lifecycle and people can play with MPA VT
<vmpstr> noamr: later on we plan to get to element view transition and expand navigation for url/back navigation/etc
<vmpstr> noamr: this is what we want to do first: navigation trigger for MPA, and readytorender event that maybe gives you a view transition that you can work with
<vmpstr> noamr: and semantic grouping where you set classes and respond to them
<vmpstr> noamr: step c is to combine these two things together
<khush> q?
<vmpstr> noamr: questions? comments?
<vmpstr> michael: for cross document navigations, i understand the desire to limit the need for js, and there is a navigation api now and so you're potentially firing these events at a similar time to intercept
<vmpstr> noamr: yes, for outgoing
<vmpstr> michael: so there is a problem for when to load, and end, and you have a placeholder like a spinner
<vmpstr> noamr: yes, currently for the new document, this doesn't help us at all since there are no navigation events
<vmpstr> noamr: for old document we thought about dealing with navigate event but also adding something for redirects
<vmpstr> noamr: so you want this not just for things clicked in the page
<vmpstr> noamr: we do want to make this work well together
<astearns> ack fantasai
<vmpstr> fantasai: if you're just doing a declarative transition between pages, there is some ttype of syntax that enables that, some class navigation
<vmpstr> noamr: right now, it's just @navigation same-origin
<vmpstr> fantasai: and what is same-origin what else can you put there?
<eeeps> q+
<vmpstr> noamr: right now nothing, but as a reader you can see this applies to same origin navigation, and later we'll be putting things that map to url patterns / back reload
<vmpstr> noamr: like you define what is a song page and play a page and a navigation between them has a class list expand
<vmpstr> noamr: we didn't want to get into this, but we had some ideas about this, navigation is always qualified by some urls, so you might have to specify something at least as broad as same origin
<vmpstr> noamr: we might also want to expand this to something that isn't same origin, we don't want existing pages to immediately upgrade to that without changes
<vmpstr> fantasai: i think it would be a good idea to fully explore the same, since the decision we make here we'll be trapping ourselves here, although we don't want to implement things we want to explore we'd want to put in here
<vmpstr> fantasai: in terms of mapping urls to classes of navigations, then can the page ... if you don't have the url or an obvious pattern, like it's a random identifier, which isn't great from url perspective but we shouldn't care, then you can't map a url pattern to types
<vmpstr> fantasai: can we handle these cases
<khush> q+
<vmpstr> noamr: we explored things to the group and we can explore this internally and explore it tomorrow
<fantasai> s/explore the same/explore the space/
<vmpstr> noamr: this is about navigation urls and types which is (missed)
<khush> q-
<vmpstr> noamr: about url patterns, we can go this way forever and in the end you can do things in javascript. if you can't map things declaratively you can do script (or in the server)
<vmpstr> noamr: we also don't want to work on the javascript api to work on this navigation
<vmpstr> eeeps: is this feature limited to same origin navigations or is cross origin in scope
<vmpstr> noamr: not in scope
<vmpstr> eeeps: but are there cases for this
<ntim> we're out of time fwiw
<vmpstr> noamr: maybe same site, or first party set
<vmpstr> noamr: join us tomorrow for details