Description
Creating a separate issue for the section at the bottom of this comment.
For the sake of both a) extreme convenience and b) tree-shaking, should we include the standard Penner easing equations from eases-jsnext? That way, a transition can use a particular easing function without the user having to include it as a helper function (though they still could), or the transition author having to include a library of functions and then do a dynamic lookup.
It could be stringly typed, like so...
<div in:fly='{easing:"elasticOut"}'>...</div>...or the identifiers could be effectively injected into the scope for the purposes of transition parameters:
<!-- I much prefer this version -->
<div in:fly='{easing: elasticOut}'>...</div>If we did the second one we could also support custom cubic bezier functions:
<div in:fly='{easing: bezier(.17,.67,.83,.67)}'>...</div>(Perhaps there's also a built-in spring function? Not sure if that's mathematically possible given how bidirectional transitions work, but maybe...)
This is, I'll concede, all a little bit magical. But the ergonomics are much better, I think — it offers a standard, easily documented, well-understood approach to easing functions which will result in the leanest possible output, and it doesn't prevent someone from doing something totally custom (we could prefer custom helpers over builtins in case of clashes, for example). And the Penner equations are fairly universal for this sort of thing.