Re: [css-transitions] Proposal and RFC: spring() timing function

> On 5 Jul 2016, at 5:59 AM, Rachel Nabors <rachelnabors@gmail.com> wrote:
> 
> I'm very happy to see timing functions that allow for more than two bounces in a transition! I've been advocating for more complex timing functions for some time and am glad to see some movement on the topic!
> 
> However, a few issues:
> 
> 1) With more and more designers building more and more complex motion in apps like After Effects looking for ways to export these effects to HTML5, there are currently no timing functions they can export their complex motion graphs to. This is a big problem that no one has been able to solve. Porting a mockup of an SVG animation from AfterEffects to HTML and CSS is a painful and complex process that involves a lot of eye-balling hacking together cubic-beziers into keyframe animations (to say nothing of how you cannot do such with transitions). I see a pressing need not just for a complex timing function to export to, but also...

Can you provide an example AfterEffects file that shows the type of complex timing function you're unable to port?

Dean

> 
> 2) ...and this is why I bring this need up here, a complex timing function could express functions like spring(), steps(), etc (and frames(), too, hopefully) and allow the creation of new, reliable timing functions in the future that build off its syntax under the hood. As to how this pertains to spring() and its cross-browser reliability, see this comment: https://github.com/w3c/csswg-drafts/issues/229#issuecomment-228260667 <https://github.com/w3c/csswg-drafts/issues/229#issuecomment-228260667>
> 
> I've put up an issue for complex timing functions, and would love to see you all weigh in on it: https://github.com/w3c/csswg-drafts/issues/229 <https://github.com/w3c/csswg-drafts/issues/229>
> 
> 
> 
> On Fri, Jul 1, 2016 at 5:51 PM Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote:
> [I don't know what client you're using, but whatever they
> On Fri, Jul 1, 2016 at 5:37 PM, Maciej Stachowiak <mjs@apple.com <mailto:mjs@apple.com>> wrote:
> >> (Alternate syntax: use units for these, like `spring(2mass
> >> 5velocity)`. Stronger connection between value and type, but also
> >> maybe weird? Unsure.)
> >
> >
> > "mass" and "velocity" aren't units, they are types of units. This would be
> > like writing "8length" instead of "8px".
> >
> > Please don't make physicists cry.
> 
> But in this circumstance they're *families* of units - velocity might
> be px/sec, or hue/sec, etc.  Classifying that as a generic unit
> "velocity" doesn't seem *too* crazy to me. (That said, this is my
> least favorite syntax possibility.)
> 
> >> (Second alternate syntax: finally invent "named arguments" for real,
> >> like some people have been agitating for for a while.  `spring(mass:
> >> 2; velocity: 5;)`?  To be less weird we'd have then go and backport
> >> this to other functions. Probably a decent idea? Need to noodle on
> >> syntax more, look at several different functions that use syntax
> >> differently.
> >
> > That's a more appealing syntax and makes it easier to figure out defaults.
> 
> Kk. This is just the more formalized version of option 1 (just do
> keyword/number pairs), and implies that we need to do the work of
> porting it back to other functions and properties.
> 
> >>> We could pick another formula that is more amenable to duration-based
> >>> springs.
> >>>
> >>> However, there is some criticism against coding an animation like this
> >>> purely on duration:
> >>> https://medium.com/@flyosity/your-spring-animations-are-bad-and-it-s-probably-apple-s-fault-784932e51733 <https://medium.com/@flyosity/your-spring-animations-are-bad-and-it-s-probably-apple-s-fault-784932e51733>
> >>
> >> That criticism is geared towards a bad API design that required you to
> >> specify a *technically redundant* duration, and if you didn't specify
> >> what the algo would have "naturally" provided you get an
> >> unnatural-looking result.
> >
> > My read is that it actually solves the spring equation in reverse and
> > computes a stiffness and mass for the given duration. There is no stiffness
> > or mass provided to the API, just damping (as a ratio, presumably relative
> > to stiffness or something) and initial velocity. So the duration is not
> > redundant.
> >
> > I think the reason the spring examples using the API look bad is that
> > authors are likely to severely underestimate the duration required for a
> > comfortable looking bounce, thus resulting in springs with crazy high
> > stiffness which look awkward even though they are technically correct.
> 
> Ah, that might be right, I didn't dive deeply into the examples given.
> If that's the case, then yeah, it implies that authors are just
> generally terrible at figuring out durations properly, and we should
> indeed avoid specifying them explicitly.
> 
> But that leans more on my other point, that this implies we should
> work more on animation sequencing, which is currently deferred to v2
> of WebAnim.
> 
> ~TJ
> 
> -- 
> Curator of Web Animation Weekly
> Speaking & Workshops
> • Apr 05 –06 SmashingConf, San Francisco
> • Apr 21 Frontend Masters, online, CSS Animations and Transitions Master Class
> • May 18 –20 Front-Trends Keynote, Warsaw
> • Jun 01 CSSconf Nordic, Oslo