- From: Dean Jackson <dino@apple.com>
- Date: Fri, 1 Jul 2016 11:19:25 +1000
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
> 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
Received on Friday, 1 July 2016 01:20:10 UTC