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

[cdoublev]

Follow up of #1012 (comment).

With the new linear() function, CSS authors now have the ability to create custom timing functions. However it can be verbose for some functions:

:root {
  --bounce-easing: linear(0, 0.004, 0.016, 0.035, 0.063, 0.098, 0.141 13.6%, 0.25, 0.391, 0.563, 0.765, 1, 0.891 40.9%, 0.848, 0.813, 0.785, 0.766, 0.754, 0.75, 0.754, 0.766, 0.785, 0.813, 0.848, 0.891 68.2%, 1 72.7%, 0.973, 0.953, 0.941, 0.938, 0.941, 0.953, 0.973, 1, 0.988, 0.984, 0.988, 1);
}

I would like to propose to accept <number> as an <easing-function>. <number> can be replaced with a math function, which is valid only if it includes a progress parameter.

:root {
  --ease-in-sin: 1 + sin(pi * (p / 2 - 0.5));
  --ease-in-quad: pow(p, 2);
  --ease-in-cubic: pow(p, 3);
  --ease-in-arc: 1 - sin(acos(p));
  --ease-out-sin: sin(pi * p / 2);
  --ease-out-cubic: (p * -1) * pow(p, 2) + 1;
  --ease-out-quad: p * (2 - p);
  --ease-out-quart: 1 - (p * 1) * pow(p, 3);
  --ease-out-arc: sin(acos(1 - p));
  --ease-in-out-sin: (1 + sin(pi * (p - 0.5))) / 2;
}

Without conditional statements, this syntax is less powerfull than linear() but it partially mirrors what people are requesting for in Web Animations (eg. keyframe = { easing: customFnTakingProgress }) in several issues, and may be simple to implement by UAs.

[martinalderson]

This would be very helpful, I'd support this!

Martin Alderson
CTO
https://tripper.guide

[Loirooriol]

These don't look like <number>s to me, they look like functions that take a <number> parameter and return a <number>.
And animation-timing-function: 123 seems very unclear to me.

[cdoublev]

<number> in animation-timing-function would define the output progress value.

A naked <number> would define a static output progress value. It would not be very usefull. animation-timing-function: 123 would produce the same overshooted effect during the whole animation's duration. Animating an element whose width is 1px with transform: translateX(1px) would move it 123px, I think.

Accepting <number> would be usefull when it is replaced with a calculation that includes the input progress value and trigonometric or polynomial functions. Many easing functions are implemented with them. calc(p) would be equivalent to linear, the "identity" easing function.

[Loirooriol]

My point is that with calc(p) you are representing a function, not a <number>. In other words, you want to drop https://drafts.csswg.org/css-values/#calc-computed-value

with used value time information, a math function always simplifies down to a single numeric value

I would instead prefer some new syntax to express functions, like

animation-timing-function: (p) => calc(p);

animation-timing-function would accept functions with a <number> parameter that return a <number>, so we know that p is a <number>, then calc() can do the type checking with «[ ]», and in this case it produces a <number>, as expected by animation-timing-function.

[tabatkins]

Right, this definitely isn't a "number". It's essentially relative color syntax, with a special p variable rather than a channel name. (Also, most of your example custom properties aren't numbers even ignoring the p thing; they're calculations, and need to be wrapped in a calc().)

If there's sufficient need I could definitely see a "custom easing function" exposed in this way, but as a specialized function, like custom-easing(<calc-sum>) with text that the special p keyword is available to represent the pre-easing progress.

However, I'd probably want to wait until linear() has had more time in the wild, to see just how often it's used in the first place, and how much we could replace with a custom function. If the answer to either is "not that much, only for some specialized applications" then sticking with just linear() is probably fine.

[tabatkins]

(Closing for now for easing-2, but without prejudice, so we should feel free to revisit this in the future.)

[tabatkins]

Actually, reopening since there are several pending issues talking about additional easing functions. They should probably all get deferred, but until we decide on that this issue shouldn't be treated differently.