Open mattgperry opened 3 years ago
Maybe inside CSS
, though? CSS.easing.cubicBezier(.17,.67,.83,.67)
Yep! Not precious over the namespace, gotta make that clear đŸ˜€
These are probably a good candidate for typed OM, CSS transforms already have something similar in that you can get out a matrix with new CSSTranslate(CSS.px(3), CSS.px(5)).toMatrix()
.
I'm not entirely sure why there's only a few functions available in typed OM, but it'd make sense to have something like that for easing:
const easing = new CSSEasingCubicBezier(CSS.number(.17),CSS.number(.67),CSS.number(.83),CSS.number(.67));
console.log(easing.valueAt(0.5));
I'm not entirely sure why there's only a few functions available in typed OM,
Because CSS is a big beast, and the design of Typed OM allows for us to define things gradually. ^_^
But yeah, Typed OM definitely needs the easing functions as values at some point, and when we do, having a convenience method that lets you explicitly evaluate it at a given progress value makes a ton of sense.
With new proposals for complex easing functions, the amount of API surface JavaScript animation libraries are duplicating is to increase.
This is a waste of bundle size when these functions are already present in the browser. This
cubic-bezier
implementation alone can cost 1kb minified, so I'm eager that when new easing curves appear there's already requirement for them to be available to JS authors.It would also ensure browser-based animation authoring tools like Framer could use the current browser's exact implementation when displaying and editing easing curves.
Proposal
A new
Easing
namespace, which contains access to the specced easing curves:This would also allow the composition of easing functions:
And their usage outside of the Web Animations API, for instance drawing visualisations: