Re: [w3ctag/design-reviews] Shared Element Transitions API (Issue #748)

The next step is that we revisit this in another call. I see it now has a milestone of 2022-08-22-week, which means the intent is to revisit it next week. 

I wonder if part of the reason it was so hard to wrap our heads around this was that the explainer was already very long, so it was hard to know what to focus on when reviewing it during the call. This is a complex feature, so it *does* need a lot of, well, explaining, but I wonder if it might be easier to digest if organized hierarchically, breadth-first. Also, despite the length, we felt there were certain pieces of the puzzle missing, e.g.:
- Some TAG members felt the problem statement was explained insufficiently. How is this different than existing transition & animation features and what are the use cases? 
- I personally got very confused at the JS code snippet:
```js
const transition = new SameDocumentTransition();
await transition.prepare(async () => {
  await updateTheDOMSomehow();
});
```
that is just repeated throughout the explainer. It took until the link you posted above for me to finally understand how this works: You start the transition by creating a `new SameDocumentTransition` instance, then make the changes to create this transition in the `transition.prepare()` callback. 
- The pseudo-element tree is described, but it's never explained what each of these pseudo-elements *is*, what does it represent, and why do we need so many of them. Several of us found this confusing. Things like the exact UA styles for these could have been in some sort of appendix instead of being the main content about these pseudos. All the explainer needed to say about this was that there are UA styles in place that make sure the default transition is a cross-fade, and that the animation is customized by overriding these UA styles.
- In general, it feels like the explainer skips over explaining things that would actually provide context to someone coming to this feature with a blank slate, and yet talks at length about things that are exceptions or edge cases. These are of course useful to know as well, but only after the basics have been understood, which was not the case for all of us.

Hope this helps a bit!

While writing this, I had some thoughts about the actual API: It would be nice if there was a way to use SET without the extensive refactoring of having to put the DOM manipulation code in the `transition.prepare()` callback, but something that is easier to make work with feature detection too (e.g. some way to signal the start and end of the transition, while DOM manipulation code remains where it was?). As an author, I wouldn't even know how to use `transition.prepare()` when using a framework that does the DOM manipulation for me.

I also just noticed that this doesn't support MPAs yet, but that's an API sketch. Since that's a pretty central use case, I'll make sure we spend call time reviewing that sketch too, and not just the SPA part of the API.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/748#issuecomment-1220531799
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/748/1220531799@github.com>