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

@jakearchibald and I had a call about this yesterday, and I think I now understand how this works and how the different pieces come together a lot better. We later discussed this again with other TAG members in a breakout.

We are aware that you have all been thinking about this for a lot longer than we have, and it's entirely possible that you've already explored all this and concluded the current API shape is a necessary compromise, but in case it helps, these were our thoughts:

- We like that MPA transitions are declarative, and would love to see a declarative syntax for SPA transitions too, as right now the two APIs feel a bit disconnected. It's also an antipattern if an author needs to write JS to animate a DOM manipulation or navigation that was not fired through JS. A declarative way to transition hash navigations within the same document could address some of that. Perhaps also a declarative way to filter view transitions by container and types of DOM mutations? This would also facilitate enhancing behavior from third party scripts with view transitions, as these often use their own events, which makes it hard to time the JS call. 
- It looks like CSS would be a more appropriate place for the declarative opt-in, rather than an HTML `<meta>` element which cannot be customized by media queries or scoped to elements in the future.
- We think it's **essential** to be able to customize the transition easily based on the elements or pages that are participating in it. Good transitions communicate, they are not just decorative. If the API makes it simple to have the same transition regardless of what is transitioning to what, but tricky to customize it, it facilitates transitions which are merely decorative.
- We think that skipping the transition and showing a warning when there is a duplicate `view-transition-name` is not Web Platform compatible. Typically in the declarative languages of the Web Platform, when something needs to be unique but isn't, is still handled gracefully (e.g. by using the first or the last one). Especially this being a CSS property, it's very easy to accidentally specify it on multiple elements, simply because it's very easy to specify selectors that match multiple elements. Also, since the root has `view-transition-name: root` anyway, how do you use that without having duplicate transition names? 

We wondered if it could prevent some of these issues and allow more room for future expansion if `view-transition-name` distinguished between the start and end state (e.g. through `old` and `new` keywords, possibly used together if the same element is both). That also prevents the user having to time when `view-transition-name: foo` will be removed from the start state and added to the end state: both can happen at once, at the same time as the event that kicks off the transition.

In general, we'd like to see a layered, gradual approach, where a small amount of declarative CSS syntax can address common use cases, more CSS can customize the transitions further, and JS is needed to customize behavior even further than that.  This is also in line with how existing CSS transitions and animations work, where syntax is gradually added to customize further, but very little syntax is needed to produce an initial result. 

We also think tighter collaboration between the designers of this API and the CSS WG could help address some of these issues.

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

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