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

> On 1 Jul 2016, at 7:38 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Jun 29, 2016 at 9:32 PM, Dean Jackson <dino@apple.com> wrote:
>> spring(mass stiffness damping initialVelocity)
>> 
>>  Simulate a spring using the solving algorithm defined by this JavaScript
>>  function [1].
>> 
>>  mass: The mass of the object attached to the end of the spring. Must be greater
>>  than 0. Defaults to 1.
>> 
>>  stiffness: The spring stiffness coefficient. Must be greater than 0.
>>  Defaults to 100.
>> 
>>  damping: The damping coefficient. Must be greater than or equal to 0.
>>  Defaults to 10.
>> 
>>  initialVelocity: The initial velocity of the object attached to the spring.
>>  Defaults to 0, which represents an unmoving object. Negative values
>>  represent the object moving away from the spring attachment point, positive
>>  values represent the object moving towards the spring attachment point.
> 
> These all look like they're <number>s? Is that intentional? Can they
> be typed in some way?  In particular, it looks like stiffness might be
> amenable to becoming <percentage>?

They are all numbers. I don't think percentage makes sense - what are
they are percentage of?

This brings up the question a few people have asked: what are the units
for all these? The answer is it doesn't really matter :) The output value
is determined by the parameters fed to the solving function. You could
assign some units if you like, but it's not like initialVelocity is in
pixels per second.

> 
>> NOTE: The definition of spring() above uses spaces to separate parameters
>> because "So I tied an onion to my belt, which was the style at the
>> time" [2]. Since all the other timing functions are comma-separated, maybe
>> it is better to be consistent?
> 
> I have mixed opinions. On the one hand, I want us to move more towards
> "functions are just named chunks of CSS syntax, and CSS syntax doesn't
> use commas just to separate values". On the other hand, consistency
> with existing stuff.  ¯\_(ツ)_/¯

I don't mind either way. I'm happy to accept spaces for the other
timing functions too, if someone wants to push that change to the specification.

> 
>> What's unusual about this form of timing function is that the animation
>> effect is now independent of its duration. The spring timing function
>> completely controls how the animation reaches its end point, and certain
>> parameter values can produce an animation that does not settle at the end
>> point before the animation duration expires (technically they never
>> completely settle).
> 
> Is it possible to get the opposite behavior, and leave one or more of
> the parameters undefined, then auto-compute them from the desired
> time?  (Just curious, I don't have a use-case in mind for this.)  The
> equation looks annoyingly non-linear, but I dunno.

The problem here is that the equation never technically settles, so we'd
have to pick some epsilon value for distance from end point and rate of change,
and then call that the end. I'm not sure how hard it would be to work
back from that to a set of inputs, but I think if we fix some of them
to default values we should be able to auto-compute at least one.

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

> 
>> We therefore also propose a new keyword for duration: "auto", which means
>> the duration will be calculated to be the time where the animation has settled.
>> 
>> NOTE: Lots of hand-waving here at the moment. Firstly, what "settle" means
>> to most people is dependent on the type of animation, and the size of the
>> animating object, and the distance being animated over. Secondly, we'd need to
>> describe how this works for a keyframed animation, where the duration applies
>> over all the keyframes.
> 
> "auto" seems reasonable here, but we also have to define what it means
> for all the other timing functions.

At the moment we were thinking that auto only makes sense for springs. I
am happy for it to be 0 or some other value if we'd rather it do something.

> 
>> The spring() timing function as described above has been implemented in
>> WebKit. It is currently exposed in the Safari Technology Preview, although note
>> that the current implementation does not handle optional parameters (you have
>> to specify them all). It's not exposed in regular Safari builds - we'll consider
>> that if we can reach consensus here.
> 
> Are the parameters currently arranged in the most useful order for
> defaulting? If they're all untyped numbers, the only way to omit is
> in-order from the end...


Yeah. This is something we were hoping to get feedback on.

Dean

Received on Friday, 1 July 2016 01:05:48 UTC