Re: [csswg-drafts] [css-view-transitions-2] Dealing with promises on old VT object (#9888)

This is a tricky one that could use author feedback: @mirisuzanne @jakearchibald @bramus. The following is a summary of discussion and tentative proposed resolution based on that.

The old Document will have an event when the navigation is about to be committed but before the browser renders/caches the last frame. We want authors to be able to set up CSS, including [type](https://drafts.csswg.org/css-view-transitions-2/#view-transition-type-descriptor), based on the destination page or skip the transition. The question is how should that API be exposed.

1. Provide a [ViewTransition](https://drafts.csswg.org/css-view-transitions-1/#viewtransition) object on this event. The `skipTransition()` API lets the author abort the transition. We're also planning to add a mutable `types` parameter to toggle types used in `active-view-transition`. The other use-case of providing the VT object is to enable sharing code for SPA/MPA cases.

   But the ViewTransition IDL has promises to track the lifecycle of transition animations. Since the old Document has no animation, promises like `ready`/`finish` conceptually don't make sense. We could model it as the ViewTransition on the old Document started off like an SPA transition but was skipped once the old DOM was captured and its state was copied over to the new DOM. So `ready` would reject and `updateCallbackDone`+`finish` would resolve, potentially when the Document exits BFCache (if it was persisted).
   
   It's unclear to us whether providing a VT object here with this default behaviour of promises is ergonomic or error prone, shared code mistakenly assumes the transition failed because `ready` rejected.

2. The other option is to introduce a new IDL (`SnapshotViewTransition`) which is the `ViewTransition` equivalent for the Document which provides snapshots for the start state but doesn't run animations. This would have a subset of the `ViewTransition` APIs but no class relationship.

   The pro of this is that its future proof. If we add more APIs to ViewTransition, we don't have to shoehorn a meaning for the old Document's object which might not make sense. The con is that sharing code with SPA libraries might be harder.

**Proposed Resolution**: Option 1, use the VT IDL on the old Doc with default behaviour for promises (and new APIs as they are introduced).

-- 
GitHub Notification of comment by khushalsagar
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9888#issuecomment-1927903133 using your GitHub account


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

Received on Monday, 5 February 2024 19:38:24 UTC