[csswg-drafts] [css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations (#8804)

khushalsagar has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions-2] Support ViewTransitions for same-origin cross-document navigations ==
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](https://github.com/w3c/csswg-drafts/issues/8048).
   
   * It’s unclear whether all navigations initiated via the browser UI should allow a ViewTransition. More discussion at [8783](https://github.com/w3c/csswg-drafts/issues/8783).
   
   * Should reloads run a ViewTransition? More discussion at [8784](https://github.com/w3c/csswg-drafts/issues/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](https://github.com/w3c/csswg-drafts/issues/8684).
   
   * Whether the navigation will result in a change in Document is known. For example a [204 response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204) could make the navigation a no-op. More discussion at [8782](https://github.com/w3c/csswg-drafts/issues/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](https://github.com/w3c/csswg-drafts/issues/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](https://github.com/w3c/csswg-drafts/issues/8790).

   * Wait for the next rendering opportunity and execute “[capture the old state](https://drafts.csswg.org/css-view-transitions-1/#capture-the-old-state)” algorithm. This state is transferred to the new Document.
   
   * Set document’s [transition suppressing rendering](https://drafts.csswg.org/css-view-transitions-1/#document-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](https://github.com/w3c/csswg-drafts/issues/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. TODO(khushal): Rough syntax is [here](https://github.com/WICG/view-transitions/blob/main/explainer.md#script-on-new-document). This should give the author a reference to a subset of ViewTransition IDL. File an issue.
   
   * Wait until all [render-blocking resources](https://html.spec.whatwg.org/#render-blocking-mechanism) 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](https://drafts.csswg.org/css-view-transitions-1/#setup-view-transition-algorithm:~:text=If%20the%20promise%20was%20fulfilled%2C%20then%3A) 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8804 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 5 May 2023 22:47:42 UTC