[css-easing-2] Custom curve-based easing functions

[jakearchibald]

#229 was solved with linear(), which allows easings to be defined by a series of points that are linearly interpolated.

Many easings are curve-based, so there's space for a more efficient syntax that allows curves to be defined.

Some ideas/points from #229:

• cubic-bezier() isn't great, since it's a 2D concept that's being applied to something that's fundamentally 1D. [css-easing-2] Complex easing/timing functions #229 (comment)
• Piecewise cubic splines [css-easing-2] Complex easing/timing functions #229 (comment)
• Could use SVG paths, but would need to do something about the case where one input has many outputs [css-easing-2] Complex easing/timing functions #229 (comment)
• Could join multiple cubic-bezier() functions together [css-easing-2] Complex easing/timing functions #229 (comment)
• More cubic-spline() ideas [css-easing-2] Complex easing/timing functions #229 (comment)

[tabatkins]

To finish out the list of currently-suggested additional easing ideas:

• spring(): "bouncy" easing. Dean's suggestion produces its own duration; other variants can be duration-independent.
• JS-driven easing: use a JS function (takes an input number, produces an output number) to drive an easing
• midpoint(): reproducing the easing behavior of gradients, so easing functions can be integrated into gradients more smoothly
• stacking easing functions: applying one, then sending that value to another
• chaining easing functions: hooking several together end-to-end, like successive cubic-beziers
• math-based easing: like custom-easing(sin(p)), a calculation with a calc variable p for the progress
• smooth: a new cubic-bezier keyword that auto-computes based on surrounding easings in a keyframe animation to produce a c1-continuous curve

Agenda+ to discuss at TPAC, to see if we want to pursue any of these right now, or defer them.

[css-meeting-bot]

The CSS Working Group just discussed [css-easing-2] Custom curve-based easing functions.

The full IRC log of that discussion

<fantasai> TabAtkins: Easying 2 spec added linear() function
<fantasai> TabAtkins: which allows any timing function you want in theory, but annoying if non-trivial function
<fantasai> TabAtkins: so there's a big batch of suggestions for other timing functions
<fantasai> TabAtkins: Possibilities include
<fantasai> piecewise cubic splines
<fantasai> SVG paths
<fantasai> other cubic-splines ideas
<flackr> q+
<fantasai> cubic-bezier
<fantasai> spring
<fantasai> midpoint
<fantasai> stacking easing functions
<fantasai> chaining easing function
<fantasai> easing based on math, e.g. supply a sin() function or whatever
<fantasai> JS-driven easing functions, 2 variants
<fantasai> TabAtkins: I want to decide which ones we want to include in easing 2 vs defer
<fantasai> TabAtkins: inclined to do just chaining and cubic-splining
<fantasai> TabAtkins: but could also be sold on spring
<kbabbitt> q+
<fantasai> TabAtkins: otherwise at some point will ask for a cutoff
<emilio> q+
<fantasai> TabAtkins: opinions?
<astearns> ack flackr
<ydaniv> q+
<fantasai> flackr: Don't have strong opinions on which specific function
<fantasai> flackr: but if using automatic duration for spring(), usually compute based on a distance
<fantasai> flackr: but animations don't currently have a distance
<fantasai> flackr: some hard to know what it would be, others there's no distance (e.g. color)
<fantasai> flackr: so we'll need an answer to that if we want to do it
<astearns> ack kbabbitt
<fantasai> kbabbitt: I only have an opinion on JS-driven. I understand desire, but either need to super constrain or will not be able to run performantly
<fantasai> TabAtkins: if JS available, generating a sufficient precise linear() is trivial, just do it
<astearns> ack emilio
<fantasai> emilio: 1st comment in issue also mentions SVG paths
<fantasai> emilio: how would you do that?
<fantasai> TabAtkins: similar to cubic-bezier()
<fantasai> TabAtkins: restrictions force it to be a function (one y per x)
<fantasai> TabAtkins: idk, don't think we should pursue
<fantasai> emilio: [mumble]
<astearns> ack ydaniv
<fserb> q+
<fantasai> ydaniv: I think we can pursue the math function one
<fantasai> ydaniv: using same syntax we have today for relative color
<fantasai> ydaniv: it will probaby kill the JS-driven use cases
<fantasai> ydaniv: and will cover a lot of easings that can be closely handled by cubic-bezier etc.
<fantasai> ydaniv: so that's worth trying
<fantasai> ydaniv: regarding spring(), might be difficult if we define something that gives you a duration that's not immediately known
<fantasai> ydaniv: stuff in Web Animations 2 like group effect
<fantasai> ydaniv: might need to know animation duration ahead of time
<fantasai> TabAtkins: integration with other types of animations makes me uncertain about an easing that has its own duration baked in
<fantasai> TabAtkins: more things to answer
<astearns> ack fserb
<fantasai> fserb: +1 to avoid the cubic-bezier and to use spline
<fantasai> fserb: because the code to handle that is awful
<fantasai> fserb: I think spline? is generic enough
<fantasai> fserb: if can do chaining etc then should be good enough
<fantasai> fserb: I think math-based is not good. Chaining is easier to understand
<fantasai> fserb: given that ? is not easy
<fantasai> fserb: given what I've seen people try to do
<fantasai> fserb: I have list of advanced cases, e.g. mobiel has special easings etc.
<fantasai> s/mobiel/mobile
<fantasai> TabAtkins: idk if multi-spline is fully general, but it can do a lot of htings including spring
<fantasai> fserb: Way specified, it allows for discontuity
<fantasai> astearns: enough feedback, Tab?
<TabAtkins> TabAtkins: yep

[tabatkins]

Quick summary of the discussion in the room (not final by any means)

• @ydaniv thinks the "math function easing" is useful
• @fserb thinks multi-point cubic spline is sufficient for most/all (and hates cubic-bezier with a passion). Will chat with me later about mobile easing use-cases he's encountered