[css-houdini-drafts] Proposal, custom script based transitions

vidhill has just created a new issue for 
https://github.com/w3c/css-houdini-drafts:

== Proposal, custom script based transitions ==
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 ( 
https://github.com/w3c/web-animations/issues/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 https://github.com/w3c/csswg-drafts/issues/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

``` css
.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**
``` javascript
/**
 * 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**
``` javascript
/**
 * 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

Please view or discuss this issue at 
https://github.com/w3c/css-houdini-drafts/issues/269 using your GitHub
 account

Received on Tuesday, 26 July 2016 22:34:19 UTC