[css-view-transitions-1] Implicit transitions and Relative Animation

[KevinDoughty]

Relative Animation is a pattern. Some form of it is possible with Web-Animations, by animating additively from the old value minus the new value to zero. It can blend on interruption arguably better than “Faster Reversal” from the CSS-Transitions spec, and perhaps more importantly obviates the need to do work in completion handlers. A non-additive version for matrix translation has been popularized on the web as “FLIP”. I have proposed similar features before, but its implementation would introduce the possibility of other, entirely new patterns not otherwise possible or existing on any platform, one of which is explained below.

The CSS-View-Transitions-1 proposal is for creating explicit animation. Relative Animation can describe implicit exit/unmount/onOrderOut animation, without requiring the developer to manually remove elements from their parent when animation has finally completed in a callback. The caveat is a sort function is needed, with the unusual requirement that equality establishes identity.

The implementation by example, when animating the removal of the value C from the old set { A,B,C,D } to result in a new set { A,B,D }, subtracts the new from the old which is { C }, but gets added back during the duration of the animation resulting in { A,B,D,C } which still needs to be sorted. (An actual set object would not need to be sorted, but an array or nodeList would.) It is important to note multiple implicit transitions may run simultaneously, even if started at different times by different events.

An API could have pseudos ::view-transition-in and ::view-transition-out, a transition-property children to initiate this type of discrete animation, and a javascript children event handler for sorting, which takes two parameters and returns -1, 0, or 1. A default sort could check for a data-index property, or decide for you if the developer is ok with possible visual inconsistency.

Other features which I have vaguely proposed in the past are more concretely implemented in an experimental Firefox Nightly patch: https://phabricator.services.mozilla.com/D156634#5139009

Its Composite-Operation: relative and transition-composition: relative are the most important as other features can be built on them, including this proposal. Relative Animation does not need current animated values, so its incomplete and highly experimental discrete-state property enables notable performance improvement as the interruption of composited property transitions does not require style recalculations to determine current values.

From this patch, getComputedStyle and getBoundingClientRect return non-animated destination values only, which is useful for the Relative Animation pattern. This could mean for view transitions that the pseudo-tree might not even be needed and live elements be what gets animated out instead of their rasterization. Highly optimisitic, but nodeLists might be able to return destination values in the same way. An exiting element could be excluded from being reported in its nodeList without creating inconsistencies for this pattern. Maybe.

Please rename “View Transitions” to “View Animations” to be consistent with CSS-Animation and CSS-Transition naming. Transitions should be implicit, not explicit.

What happens with explicit View-Animations on interruption of an in-progress animation? Are animations and pseudo-element trees instantly replaced or can multiple run simultaneously? Are they affected by “Faster Reversal”?

Implement me!

[KevinDoughty]

A related Relative Animation pattern proposal: https://github.com/w3c/csswg-drafts/issues/8151

[jakearchibald]

I got a little lost reading this issue. It wasn't clear to me when you were talking about the current state of the view-transitions API, and when you were talking about your proposed extensions.

For example:

It is important to note multiple implicit transitions may run simultaneously, even if started at different times by different events.

This currently isn't allowed in view-transitions. The currently active transition will be skipped to the end to allow the new one to start. But maybe you're talking about your proposal, and not the current API. In which case you may be interested in scoped view transitions, which allows for multiple concurrent transitions.

subtracts the new from the old which is { C }, but gets added back during the duration of the animation resulting in { A,B,D,C }

This feels related to https://github.com/w3c/csswg-drafts/issues/7882#issuecomment-1339334717, but again I'm not sure if you're talking about the current state of things, or your proposal.

It might be easier to present a transition that's difficult in the current design, then we can look at ways to make that easier.

[KevinDoughty]

Sorry for stepping on your toes, I was debating emailing the list but ended up in the wrong place. In the future I will try to more carefully make the distinction between "implicit view transitions" and "explicit view transitions".

My proposal has a significant flaw, though, a single-source-of-truth issue with the sort function that would have to be resolved by very clear specification, which I will suggest elsewhere.

[jakearchibald]

I'd really happily hear more about this. Don't be discouraged that I didn't get it straight away 😁