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

On Tue, Jun 16, 2015 at 7:07 PM Glen Huang <curvedmark@gmail.com> wrote:

> 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.
>

Basically, you set your final state in CSS then override using the
animation. For example, before the animation starts you set:
navBar.style['justify-content'] = "space-between";

Then in your animation, you "animate" justify-content from "center" to
"center". It holds that value while it fills forwards.

When the animation is done, use the onfinish hook to cancel it, and the
value stops applying, falling back to the final state you've set up in CSS.

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.
>

Again though this is using events to set the visual state, which you really
shouldn't do. Instead, this sounds like some kind of advanced groups case -
given that we haven't nailed down basic groups yet I think it's probably a
way off before we consider looking at it.

You can in general get a mixture of fill effects by refactoring your groups
appropriately. This doesn't give you everything but it gets you a long way.

Cheers,
    -Shane

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

In general - yeah, though some of them may be difficult. Another question,
though, is 'does this hook fit with the realities of animation' - sadly the
answer here is no, because it's impossible for us to give you an event
callback in which it's safe to modify visual state.

Cheers,
    -Shane


>
> 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> 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.
>>
>
>