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

Hi Glen,

Sorry, I'm just now catching up on your feedback.

On 2015/06/25 20:58, Glen Huang wrote:
> Also curious about two things:
>
> 1. Is zero duration, forwards filled, single keyframe effect valid and
> fills with the keyframe?;
> ```
> new KeyframeEffect(el, {position: "static"}, {fill: "forwards"}) // is
> el's position static after the effect is played?
> ```

Yes, that's correct.

> 2. Are partial keyframes valid and properties specified in a keyframe
> extends to the next one?
> ```
> el.style.position = "static";
> new KeyframeEffect(el, [{
> position: "absolute",
> prop: val1
> }, {
> // is position absolute in this keyframe?
> prop: val2
> }], {duration: 1000, fill: "forwards"})
> ```

Yes, partial keyframes are valid. The defined behavior here is:

* Since there is no keyframe at offset 1 for 'position', one will be 
created with the 'neutral composition value' and 'composite: add'.[1]
* The neutral composition value is some value that, when added to the 
underlying value, produces the underlying value.[2] So in this case it's 
going to be some kind of null-like value (that, in this case, will 
evaluate to 'static' when we add it to 'static').

As a result, this should interpolate from 'position: absolute' to 
'position: static'.

Best regards,

Brian

[1] 
http://w3c.github.io/web-animations/#the-effect-value-of-a-keyframe-animation-effect, 
step 8
[2] http://w3c.github.io/web-animations/#neutral-value-for-composition

> Thanks.
>
>> On Jun 22, 2015, at 6:21 PM, Shane Stephens <shans@google.com
>> <mailto:shans@google.com>> wrote:
>>
>> On Tue, Jun 16, 2015 at 7:07 PM Glen Huang <curvedmark@gmail.com
>> <mailto: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
>>>     <mailto: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.
>>>
>>
>

Received on Monday, 29 June 2015 01:42:25 UTC