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

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'?

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.
b) A scroll-based animation that is triggered by script.

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

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

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

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.


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' ;)

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.

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 Wednesday, 10 September 2014 03:02:18 UTC