Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-easing-2] Accept <number> as <easing-function> #9184

Open
cdoublev opened this issue Aug 12, 2023 · 5 comments
Open

[css-easing-2] Accept <number> as <easing-function> #9184

cdoublev opened this issue Aug 12, 2023 · 5 comments
Labels
css-easing-2 Current Work

Comments

@cdoublev
Copy link
Collaborator

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.

@cdoublev cdoublev added the css-easing-2 Current Work label Aug 12, 2023
@martinalderson
Copy link

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

Martin Alderson
CTO
https://tripper.guide

@Loirooriol
Copy link
Contributor

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
Copy link
Collaborator Author

<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
Copy link
Contributor

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-easing-2 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants