Proposal, custom script based transitions

[vidhill]

Hello,
Might be cross-posting here, as I sent this to the mailing list too,
But I find the mailing lists awkward to keep track of..

I think this sits in an odd position in between Houdini and Web Animation API, I have also posted this there ( w3c/web-animations#161 )
I have attempted to make my example as 'Houdini consistent' as possible, but I haven't delved deeply into the spec so excuse me if I miss some conventions.

I believe this would sit somewhere near the Compositor Worker, perhaps as a variation/extension on top of the Compositor Worker

Following discussion in w3c/csswg-drafts#229 I put some thought into programmatic transitions, like Apple's spring proposal.

I've been thinking about the notion that we could facilitate custom scripted animation for transition values.

I think this sits in an odd position in between Houdini and Web Animation, I may post this on both.
I believe this would sit somewhere near the Compositor Worker, perhaps as a variation/extension on top of the Compositor Worker

Here is the proposition I have arrived at..
I have attempted to make my example as 'Houdini consistent' as possible, but I haven't delved deeply into is so excuse me if I miss some conventions.

I am using Apple's spring transition proposal as an example of a complex use case.

The css function syntax is similar to paint and layout in the Houdini spec e.g. background: paint(foo) but would allow the facility to pass options, hence the second set of parentheses.

Anyway, css would look something like this

.my-element {
    /* transition: transform 500ms transiton(simple); */
    transition: transform 500ms transition(spring)(1 100 10 0);
    transform: translate(0px, 0px);

}

.my-element.active {
    transform: translate(200px, 200px);
}

Simple example of an ease function file

File: simple.js

/**
 * The simplest possible easing function, linear
 */

function SimpleTransition() {
  // in this case constructor does nothing
}

/**
 * Function that gets called every frame until a done() callback / promise.resolve()
 * @param {float} t - Transition current Time, value from 0 to 1
 * @param {Promise} - Promise that gets resolved when animation is complete
 * @return {float} A value 0 is not transitioned at all and 1 is fully transitioned
 */
SimpleTransition.prototype.tick = function(t, animationComplete) {
  if(t === 1){
    animationComplete.resolve('done'); // when animation is complete resolve promise
  }
  return t;
}

SimpleTransition.prototype.onmessage = function(e) {
  // advise..
};

registerTransitionAnimator('simple', SimpleTransition);

Example of how something more complex, e.g. Apple's bounce transition effect could be defined using this method

File: bounce.js

/**
 * Simulate a spring using the solving algorithm defined by this JavaScript function
 * @param {float} The mass of the object attached to the end of the spring. Must be greater than 0. Defaults to 1.
 * @param {integer} The spring stiffness coefficient. Must be greater than 0. Defaults to 100.
 * @param {integer} damping: The damping coefficient. Must be greater than or equal to 0. Defaults to 10.
 * @param {integer} The initial velocity of the object attached to the spring. Defaults to 0, which represents an unmoving object. Defaults to 10.
 */
function SpringTransition(mass, stiffness, damping, initialVelocity) {
  // code that need to be run once during initialization
    // -real code
  //
}

/**
 * Function that gets called every frame until a done() callback / promise.resolve()
 * @param {float} t - Transition current Time, value from 0 to 1
 * @param {Promise} - Promise that gets resolved when animation is complete
 * @return {float} A value 0 is not transitioned at all and 1 is fully transitioned
 */
SpringTransition.prototype.tick = function(t, animationComplete) {
  // -real code
  // -real code
  return result;
}

SpringTransition.prototype.onmessage = function(e) {
  // advise..
};

registerTransitionAnimator('spring', SpringTransition);

The browser would know up front about the function and could, I assume be prepared,

Different variations of the spring, for example could be achieved by passing different values into the init function, which could be done from the CSS, no need to touch the js.
A designer unfamiliar with javascript could tweak the animation from CSS only.

Obviously some code savvy people could share their functions with the community, and feasibly come up with some very clever stuff. And it would not need to go through the standards process, in the spirit of the Houdini project

The frame function would at maximum be executed every frame,
But of course the browser could decide to drop/skip frames if it needed,

The browser itself could work out how much rounding would happen.

The scope of what the script could would be extremely limited..
As the only thing the script could do is return a value 0-1 obviously overshooting 1 if the ease necessitated

[ianvollick]

Hi vidhill,

It’s true that the current CompositorWorker API does not allow you to assign behaviors via CSS, and your proposal certainly does make this possible. The customization of transitions is interesting, in particular.

That said, our current API is just a stand-in and we intend to change the API to be more Houdini-like in the near future. I’d presented sketches of what this might look like last year, and some have similarities to your proposal.

But even this is still a work in progress -- we’re hoping make our first concrete API proposal shortly. In addition to the single element property animation that your approach permits, with our upcoming AnimationWorklet proposal we will be trying to address a bit of a wider variety of use cases:

• We would like to operate on more than one element at once (imagine some UI elements attached via springs and struts, eg).
• We would like to modify more than one property in a single invocation of the JS update function rather than emitting a single time fraction, and
• We would like to be able to gather information and send it back, asynchronously, to the main thread (consider implementing IntersectionObserver on top of this feature).

[FremyCompany]

Just wanted to mention that I do like the idea a lot, but agree with Ian and Shans that we will have to land the fundamentals first before adding exciting features like this. Once we have a compositor-worker and a layout-worker, so many stuff will become possible for a very small cost to implementers...

[vidhill]

The Animation Worklet Proposal, likely crosses over/goes further that what I proposed here..
https://github.com/majido/animation-worklet-proposal/blob/gh-pages/README.md

[FremyCompany]

I think I agree with you, that spec would enable you to do just that.
Do you believe w can close the issue, then?

[vidhill]

I would suppose so