Re: [web-animations] Freeing up forwards-filling Animation objects

element.animate(animation [, name]);

element.animate(effect, timing [, name]);


This would permit usage patterns that avoid your stated problems, and would
not break existing code. Just add a third argument. It would still be
possible to add forward filling animations with an undefined name. This is
undesirable but easily avoided.


elem.addEventListener('click', evt => {

    evt.target.animate({ opacity: [ 0, 1 ] }, { duration: 500, fill:
'forwards' }, 'myAnimation');

});


Some other methods would be needed to manage this:

animationNamed(name);

removeAnimationNamed(name);

removeAllAnimations();

animationNames();

allAnimations();


This resembles Core Animation, the API that CSS Animations and Transitions
were based on. I’m pretty sure Shane Stephens suggested keyed (named)
access to animations on this list a few months ago.


Along with this all animations should be automatically copied after being
added to an element, as well as when returned from querying an element for
currently playing animations. They would effectively be immutable. This
might break existing code. Keeping instances around would be useless except
as templates. Changing various settings on animations would have no effect
on the outcome of currently playing animations because you would be
operating on copies. Then maybe we could have group animations back as
there wouldn’t be conceptual problems with mutation. You could only remove
them, or replace them by using the same name.


I’ve already sort of requested something like “animation-blend” or
“transition-blend” with possible values: “absolute” (the default), and
“relative” (old minus new to zero). In my own rAF based animation I also
have a third, “zero” blend mode which is for virtual-dom like API with a
render function so it probably won’t be useful unless Houdini Properties
and Values allows triggering implicit transitions on value change of
arbitrary properties of javascript objects instead of inline CSS styles of
DOM elements. Some other time perhaps.


To get the relative pattern, along with converting values from absolute to
relative, something like “transition-naming” would allow using keys (names)
of the property being transitioned or exactly as stated if created from
javascript: “exact” (the default), or with auto-incremented numbers
appended: “increment”. Alternately there could be an accessor like:


animationsNamed(name); // animations plural


Additive animations with the same name would not replace each other but get
stored in an array which this function would return. Neither is especially
appealing, but I would prefer one of them (the former) to being required to
use Houdini Properties and Values to trigger every transition from
javascript.


Copying animations is important, which would require a way to recall
animations via animationNamed(name). Otherwise an undefined key is ok. You
could manually increment a name yourself for additive animations created in
javascript, but some sort of automatic handling of keys would be required
for relative CSS Transitions. Relative animation is still not possible in
Apple’s AppKit view animation without method swizzling (monkey-patching)
because they automatically give implicit animations (like CSS Transitions)
a specific key, that of the property being animated (in most cases). This
prevents multiple animations on the same property running concurrently even
if they are additive, thus the naming treatment.


I’m sure many others would choose the simpler, CSS Transition default
approach of replacing any previous animation with a new one that begins
where the previous left off, maybe even with your to-animations blending,
maybe even forward filling, by simply giving animations created in
javascript a name.


Some examples of what I’ve been doing lately:


Animation of the planet (cookie) uses a name so animations can be recalled,
copied, and queued. Also, relative keyframes A B C D E, converted to old
minus new, becomes A-E, B-E, C-E, D-E, E-E. This uses a framework called
“Hypermatic” which I do not recommend anyone use, rather just admire the
usage.

http://codepen.io/kvndy/pen/YyXLWp?editors=001


I have a new framework called “Shoe” for Core Animation-like layers using
javascript objects. Animated (calculated) values are provided to the render
function, everywhere else you get specified values. This is in stark
contrast to animation techniques in React, for example, which requires
manual conversion in the render function. An easy task, perhaps, but then
again DOM manipulation is also easy.

http://codepen.io/kvndy/pen/KdrWKN?editors=001


It is meant for objects with a render function, which could not possibly be
any cleaner than in this next example. The “zero” blend mode only works in
Chrome and FF thanks to 5.21 Model Liveness “Changes made within the same
task are synchronized such that the whole set of changes is rendered
together”. Otherwise, I’m sorry to say, I don’t have much use for
Web-Animations.

http://codepen.io/kvndy/pen/ojJqBZ?editors=001