Re: [web-animations] Bubble animation events to effects

The conversation unfortunately died.

Maybe the use cases aren't compelling enough. That's totally fine. The only question I have is that in the responding mail, you said

> You can do this with closures too. Just toggle the class in the classList.

But I don't think I can.

Your original suggestion was that I should negate styles in the keyframes, and since the effect is only backwards filled, those negations will go aways when the effect is no longer active.

Now, by toggling class I assume you mean I should put these negations inside a class and enable that class when closure is called? But now when the effect is no longer active, the class won't be removed automatically. So when do I remove it manually? There is no hook in the effect to notify me when the effect is no longer active.

I have another use case that could be covered by this hook: when multiple effects are nested, I want some of them to fill forwards, but others to fill forwards until the root effect is no longer active. With this hook, I can change the nested effect's fill to none in the hook of the root effect.

So the question is, since such hook doesn't exist, is there any other way to achieve the things I described?

Thank you very much.

> On May 27, 2015, at 3:24 PM, Shane Stephens <shans@google.com> wrote:
> 
> Hi Glen,
> 
> 
> 
> On Wed, May 27, 2015 at 5:09 PM Glen Huang <curvedmark@gmail.com <mailto:curvedmark@gmail.com>> wrote:
> Hi, I recently tried to manage very complex animation, and realized I need this feature:
> 
> When animations fire ready and finish events, they first bubble into to the associated effects, if effects have nesting children, recursively bubble into them, after that, bubble back to animations, much like how dom events work.
> 
> Do you think it makes sense?
> 
> I think it sounds complicated, and it doesn't match the intention of events well. If you have some specific examples where you want this behavior, perhaps we can work through them with you?
>  
> My use case is like this:
> 
> There are many components in a page. Each different combinations of them can chain together to create an animation. To make things manageable, I design the components so that they can each return effects pertaining to its part in different animation sequences. And when a particular animation is required, I select the corresponding components and their corresponding effects, composite these effects and play it.
> 
> The difficulty is that each components now only has control for its turn in the animation, but sometimes it needs to change styles after/before the whole animation sequence (e.g., pull itself out of flow before/after the animation).
> 
> You must be walking your component list to generate these animation effects. Why not generate closures for what you need to do before the animation sequence starts while walking the list, then apply them centrally when you start the animation?
>  
> With the proposed API, it's as simple as changing styles in the corresponding event hooks.
> 
> Yes, but at the cost of a great deal of complexity in the implementation. You're also assuming synchronous events (more on this below).
>  
> However, Shane suggested an alternative solution: before the animation starts, change each component's styles to the desired final value, and use backwards filled effect to negate the styles before animating.
> 
> I think it's a nice solution, but there are a few problems:
> While returning effects, components' methods need to add/remove styles. You can't embed these actions into the effect itself. This means the effect must be played in the next tick after they are created, which isn't always feasible.
> Store the effect update in a closure, and run the closure from the same function that plays the animation. 
> This solution requires you to always put the component in the final styles first, but sometimes the component is easier to animate upon the current styles, and only change to the final styles after the animation is finished.
> Given that additive animation is not yet implemented I can't understand why this would be true. 
> Negating the styles can be difficult, especially vendor prefixes are involved. With event hooks, you can use temporary classes to negate the styles, relying on tools like autoprefixer to deal with vendor prefixes.
> You can do this with closures too. Just toggle the class in the classList.
>  
> So, in summary, i think bubbling events to effects should make managing complex animation much easier, and would like to hear your thoughts on this.
> 
> P.S. In order to make these event hooks practical, I think we should force that the two events should fire in the same event loop as that of the first/last frame. In other words, for example, changing styles in the finish event of a non-forwards filled effect shouldn't cause FOUC.
> 
> We considered and rejected synchronous events some time back. It's impossible to synchronize with the compositor thread.
> 
> In general, you should not be making visual changes in event handlers. They can never be genuinely frame-aligned, so doing so is just going to be setting yourself up for FOUC or inconsistent behaviors between browsers.
> 
> Cheers,
>     -Shane
>  
> Thank you.