[web-animations-2] Allow multiple root effects per animations

[verbessern]

Greetings to everyone, I think that instead of having one effect per an animation, there should be a sequence. Additionally I think that an effect should be sharable between elements, and the concept of a 'target element' should be changed to 'target elements'.

[birtles]

I've updated the title here to reflect what I understand the proposal to be. However, please write a concise summary of what the problem is you're trying to solve. It's much easier to get interest and input from others if you can clearly describe the problem, rather than the solution.

[verbessern]

Thank you, I understand.

• I think that its a very common case, that one animation will be applied to more then one effect.
• to implement this, the current specification WA2, requires one to create a multiple instances of the same animation, duplicate its parameters and connect it to the different effects.
• the other way to do it, is to create a group effect, but creating additional instances (groups) is unnecessary waste of a runtime memory and performance.

I propose that one animation have a sequence of effects, instead of a single 'target' effect. In this way, there will be no need to waste the resources for more the one animation or grouping. The groups can be used only to facilitate some other significant processing (as a time change), but not for the sole purpose of grouping, that could be made by a simple sequence field.

And second, I propose more then one element to be targeted by the effect. That will also free the implementations of duplicated instances when the same effect will be applied to more then one element.

I don't think that sharing values thru property bags or other structures is a solution, because that implies that such structures are available (regardless of is that easy or not to implement). I think that the specifications should be general and reflect pure logic without assumptions.

[majido]

/cc @yi-gu

It is not clear to me how the proposed "sequence of effects" is different that SequenceEffect that is part of the GroupEffect proposal in web-animations 2.

The current proposal for GroupEffect has a very appealing property that the group and leaf node in the tree have the exact same interface (i.e., the composite design pattern). So it supports creation of complex tree of effects without complicating the API. I like us to keep that.

And second, I propose more then one element to be targeted by the effect. That will also free the implementations of duplicated instances when the same effect will be applied to more then one element.

This is interesting. Basically the current group effect require the author to create individual animation effects and group them. In many cases, the timing and keyframes for these individual animation effects are shared. So it is repetitive and sub-optimal to create them individually. I believe your argument about "waste of runtime memory and performance" also refers to this.

I can see us adding new constructors to various Group Effect (Sequence, Parallel, Stagger), where the same keyframes and timing data can be shared.

Here is a strawman API:

const targets = docuument.querySelectorAll('div.animated');
var effects = []
const timings = {duration: 100}
const keyframes = {transform: ["translateX(0)", "translateX(100%)"]}
for (var t of targets) {
    effects.push(new KeyframeEffect(target, keyframes, timing);
}
const animation = new Animation(new SequenceEffect(effects));
animation.play();

Alternative constructor to create a sequence effect with same keyframes, and timings but multiple targets.

const targets = docuument.querySelectorAll('div.animated');
const timings = {duration: 100}
const keyframes = {transform: ["translateX(0)", "translateX(100%)"]}
const animation = new Animation(new SequenceEffect(targets, keyframes, timing));
animation.play();

I can imagine a similar constructor for Parallel and Stagger effects as proposed here.

I personally agree that the second one is more ergonomic and can be better optimized. If supporting it requires just adding a second constructor to the existing model, I think the additional constructor is valuable enough and carries its weight.

On the other hand, if this mean throwing out the existing interfaces with their nice composite property I don't think it is justified.