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

Hi Glen,



On Wed, May 27, 2015 at 5:09 PM Glen Huang <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.
>