[Request] Expose cubic bezier function

[cibernox]

I'll expose my use case:

I have an animation that has an ease-in-out easing that displays a slider menu.
This animation can be triggered with a button or being animated with the touch move event. For that, I set the currentTime based on the % of the route mi finger has made.

In a linear easing, if the animation translates the menu 320px, having moved my finger from X=0 to X=290 means that i've completed the ~90% of the animation, and I must set the currentTime to the 90% of the total duration.

With a non-linear easing, I have to apply the inverse cubic function to find what currentTime I have to set in the animation to make the translation be where I am touching the screen.

The inverse cubic function is that function that composed with the easing gives me the linear function. Begin my easing f(x) = y, the inverse satisfies that g(f(x)) = x.

With cubic functions it's very easy, I just have to swap each pair of values.

The inverse of cubic(0.1, 0.2, 0.3, 0.4) is cubic(0.2, 0.1, 0.4, 0.3).

In a nutshell, I think that this use case might be needed by more people, and would be nice to expose the cubic function in the public API.

Right now I am using https://github.com/gre/bezier-easing, but I would like to avoid to use another library for something is already built in the this polyfill.

Would you agree with a PR on that direction?

[shans]

Unfortunately, we're constrained here - the purpose of this library is to polyfill the specification until native implementations are available on all browsers. Ideally, this repository will eventually be completely superfluous.

While I'd really like to be able to expose bezier features, this would force websites to continue to rely on the library even after native web animations support is universally available.

[cibernox]

In that case maybe it makes sense to raise this feature request to the spec authors. If they want to allow JS to run declarative animations, a built-in CubicBezier is must for me.

At the end of the day, every browser supporting CSS transitions already have a cubic bezier engine inside.

Which is the best place to suggest it?

[shans]

I'm one of the specification authors.

If you want to provide an idea for (or feedback about) the specification,
the best place to send it is public-fx@w3.org. Be sure to prefix your
subject line with [web-animations].

I'd be surprised if we included bezier functions in level 1 of the
specification - as the API is currently specified you can solve a timing
function for a given 'x' by applying it to a new animation, creating a
player, seeking the player to 'x', then looking at the animation's
computedTiming.timeFraction (note that the computedTiming interface isn't
implemented in the polyfill yet):

function solve(tf, x) {
var a = new Animation(null, [], {duration: 1, easing: tf});
var p = document.tineline.play(a);
p.currentTime = x;
var y = a.computedTiming.timeFraction;
p.cancel();
return y;
}

I realize that this is somewhat cumbersome, so we might be interested in
putting a more specific API into a later level. I do agree with the general
principle of exposing native functionality through APIs where feasible.

Sincerely,
-Shane Stephens

On Sat Jan 17 2015 at 10:39:45 PM Miguel Camba notifications@github.com
wrote:

In that case maybe it makes sense to raise this feature request to the
spec authors. If they want to allow JS to run declarative animations, a
built-in CubicBezier is must for me.

At the end of the day, every browser supporting CSS transitions already
have a cubic bezier engine inside.

Which is the best place to suggest it?

—
Reply to this email directly or view it on GitHub
#270 (comment)
.

[cibernox]

@shans Thanks!
I've just sent a mail to the mailing list.

Just on question. None of the articles I've read about the spec mentions the new Animation syntax. I've only seen the element.animate. I haven't read about AnimationGroup and AnimationSequence either.

They are/will be part of the spec or is just part of this polyfill?

[shans]

Hi Miguel,

They're part of the editor's draft and current working draft of the
specification but we're likely to defer them to level 2. The polyfill
demonstrates that they are implementable on top of element.animate, so
they're not essential; and there are still significant open questions
around Groups and Sequences in particular.

Cheers,
-Shane

On Sun Jan 18 2015 at 9:07:56 AM Miguel Camba notifications@github.com
wrote:

@shans https://github.com/shans Thanks!
I've just sent a mail to the mailing list.

Just on question. None of the articles I've read about the spec mentions
the new Animation syntax. I've only seen the element.animate. I haven't
read about AnimationGroup and AnimationSequence either.

They are/will be part of the spec or is just part of this polyfill?

—
Reply to this email directly or view it on GitHub
#270 (comment)
.

[cibernox]

Great, thanks for the insights.

I'm closing this then, and keep using a library for now.