[csswg-drafts] [css-view-transitions-1] Implicit transitions and Relative Animation (#8152)

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

== [css-view-transitions-1] Implicit transitions and Relative Animation ==
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!

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


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

Received on Wednesday, 30 November 2022 00:06:32 UTC