What I also would _love_ is a function based on velocity, or speed per logical pixel. So that a transition that happens over say 200px does not take the same time as the same transition happening over 450px.
--myidea-tranistion-timing: 1px/5ms;
The above would take one second (200pixels at 5ms per pixel) to transition a 200px distance, and would take 2.25 seconds to transition 450px because the velocity would be the same.
That would be awesome — I have found myself wishing for a similar CSS-only solution. In the meantime, I've resorted to measuring the translation distance in JS, and multiplying that by the average duration I want the element to spend in each pixel position (usually a few milliseconds).
> Bézier curves are great, but there are certain things they just can’t do. For example:
It would be nice if we had a better explanation of what is wrong with the Bézier curves in the example. I've put the spring Bézier example side by side with the javascript simulated one, had them both trigger at the same time on a keyboard press and I can barely notice a difference; one doesn't look better than the other to my eyes.
Where do you see a Bezier-based spring example? I think the one in the section you quoted is just to show what a spring animation looks like, so you know what you're missing by sticking to Bezier curves.
I'm on my phone right now, so I can't actually verify how the one in that section is implemented.
