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

> On Jun 30, 2016, at 6:19 PM, Dean Jackson <dino@apple.com> wrote:
> 
> 
>>> On 1 Jul 2016, at 11:12 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> 
>>> 
>>> On Jun 30, 2016, at 2:38 PM, 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>?
>> 
>> The canonical units for these values in a damped spring model would be
>> mass: kilogram
>> stiffness: Newton/meter (force over distance)
>> damping: Newton-second/meter (force over velocity)
>> initialVelocity: meter/second
>> 
>> I think CSS does not support these units, and it's not clear that it would make sense to add them. None of them is sensibly regarded as a percentage.
>> 
>> (I'd guess Sam and Dean may have rescaled these
> 
> No, we didn't.
> 
>> but any units for these quantities in a spring model would differ by at most a constant factor. One possibility that seems appealing is to give velocity in px/s rather than m/s, and rescale other units appropriately.
> 
> But it's not always pixels you're moving. e.g. hue degrees per second? :)
> 
> That's why I think it's just not worth trying to explain it. The inputs go into a function along with the elapsed time and out comes a value that should eventually move from 0 to 1 (but isn't restricted to that range during the animation). Twiddle the values until you get something that looks good.
> 
> Dean

For velocity, percentage per second makes a certain amount of sense to me, with it being a percentage of the distance between start and stop points. That "distance" could be along a color spectrum, for colors.

Received on Friday, 1 July 2016 21:44:54 UTC