Re: [css-animations] Proposal for animation triggers, timebases and additive behavior

> On 10 Sep 2014, at 1:01 pm, Brian Birtles <bbirtles@mozilla.com> wrote:
> 
> On 2014/09/10 7:58, Dean Jackson wrote:
>> animation-timebase
>> -----------------
>> 
>> Name: animation-timebase
>> Value: auto | scroll | url(<media element>)
>> Initial: auto
>> Inherited: no
>> Animatable: no
>> 
>> The animation-timebase property defines how the time value will advance.
>> 
>> The default value is "auto", which means the animation uses the normal document
>> timeline (as it does today).
>> 
>> A value of "scroll" means the timeline of the animation will be driven from the
>> scrolling container's position. This works in conjunction with the
>> animation-trigger, such that the duration of the animation is mapped onto the
>> length of the trigger. In Example 2 above, 100px would be equivalent to 0s and
>> 500px would be equivalent to 300ms, meaning the animation would play through
>> once as you scrolled.
> 
> Does this mean it's not possible to use 'animation-timebase: scroll' without using 'animation-trigger'?

It should be - I just think my text is misleading. In most cases you will want them both, but there is no reason you can't have only one.


> 
> I don't really understand how you achieve:
> 
> a) A scroll-based animation that is always on. i.e. It starts as soon as you start scrolling the page.

I think that would be what happens if you said animation-timebase: scroll by itself, or had a scroll trigger at 0px.

> b) A scroll-based animation that is triggered by script.

I'm not sure what you mean here, sorry.

> 
>> Obviously scrolling up the page would effectively reverse the time.
>> 
>> If the animation does not have an end trigger, "scroll" acts like "auto" (or
>> should there be a defined end? My example below uses the end of the page as the
>> end trigger.).
>> 
>> A value of "url()" references a media element that acts as the timebase. The
>> duration of the media maps to the duration of the animation.
> 
> This matches closely with some ideas we've been considering.[1]
> 
> I've been calling this property 'animation-timeline' and representing it in the API as different subclasses of AnimationTimeline, such as ScrollTimeline. The "url()" syntax above would perhaps correspond to a MediaTimeline of some sort?

Yeah. Ultimately you could probably reference any element that has an animation, but then you get into the tricky situation of working out which animation you want to use. I think starting with MediaTimelines makes sense for now.

> 
> We'd like also to see timelines that map to touch gestures eventually (and maybe even frame-based timelines, script-defined timelines?).

Great.

> 
>> NOTE: There should be a way to map the duration *range* of the media to the
>> duration of the animation, so that you don't need to know the media duration in
>> order to make a progress bar.
> 
> In [1] I was considering the idea of using the animation's playbackRate to control the mapping between timeline time (scroll units) and animation time.

Ignoring timelines that reference media for a moment, I originally wanted to provide control over the scroll mapping, but in experimentation realised that you could tweak the animation to get the effect you wanted. This effectively means animation-duration is ignored, because we're mapping from 0 duration to elapsed duration when providing the timeline. 

However, this does make it hard to do some repeating animations (you'd have to create more keyframes), so maybe there should be a way to control the mapping scale.

For timelines that come from media, I think there are two ways to map: animation duration maps onto media duration, or media time is fed directly in. Both are valid use cases. I didn't consider infinite timelines (such as a live media stream).

> 
> Then, if we introduce the distinction between infinite timelines (e.g. the document timeline) and fixed-length timelines (e.g. media timelines, scroll-based timelines where the scroll range is limited or where the 'animation-trigger' property limits the range) then we could add some mapping for times onto fixed-length timelines.
> 
> I was considering add an "auto" value for playbackRate that would stretch the animation content to the length of timeline for fixed-length timelines. It's somewhat unsatisfying, though, because it makes the absolute values of animation times somewhat arbitrary.

All great feedback. I think we should try to accommodate all this.

> 
> 
> This is getting a bit far ahead, but one additional class of use cases I've been considering is infinite animations.
> 
> A concrete example is mapping. The timeline is driven by a pinch-zoom gesture. The animation affects the transform property of some element, setting a scale transform. The difficulty is there is no obvious limit to how far you should be able to zoom in or out. It's just an unbounded effect but it's also an effect we want to model in this way so that it can be performed entirely on the compositor.
> 
> But how do you define such an animation? Suppose we manage to set up a gesture timeline so that roughly 1cm of pinching-out corresponds to 100s, and suppose we have a second gesture timeline for the pinching-in case. I *think* we could do something like:
> 
>  animation-name: zoom-in, zoom-out;
>  animation-timeline: pinch-out, pinch-in;
>  animation-duration: 100s;
>  animation-composite: add;
>  animation-iteration-count: infinite;
>  animation-iteration-composite: accumulate;
> 
>  @keyframes zoom-in {
>    from {
>      transform: scale(1);
>    }
>    to {
>      transform: scale(2);
>    }
>  }
>  @keyframes zoom-out {
>    from {
>      transform: scale(1);
>    }
>    to {
>      transform: scale(0.5);
>    }
>  }
> 
> (The 'animation-composite' part is my covert attempt to rename 'animation-behavior' from my previous mail[2] without being seen to bikeshed. As a UK English speller I'd like to avoid 'behavior' ;)

Me too. It pained me to write it that way.

> 
> The 'animation-iteration-composite' part here corresponds to the 'iteration composite operation' property defined in Web Animations which defines how subsequent iterations build on top of each other (this is needed for SVG).[3]
> 
> The end result is you have a computed value of transform that looks like:
> 
>  transform: <any specified style> <zoom-in-scale> <zoom-out-scale>
> 
> Anyway, like I said, this part is probably getting too far ahead.

It's a good idea but I agree it might be a bit advanced. My main question is whether or not adding what I propose (simplified) will make future enhancements difficult. On the other hand, CSS animations are not meant to solve everything - so I'm happy if Web Animations is necessary for really fancy things.

Dean

> 
> Best regards,
> 
> Brian
> 
> 
> [1] https://wiki.mozilla.org/Platform/Layout/Extended_Timelines
> [2] http://lists.w3.org/Archives/Public/www-style/2014Sep/0145.html
> [3] http://dev.w3.org/fxtf/web-animations/#dfn-iteration-composite-operation
>

Received on Thursday, 11 September 2014 00:10:50 UTC