W3C home > Mailing lists > Public > www-style@w3.org > June 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 30 Jun 2016 14:38:32 -0700
Message-ID: <CAAWBYDD2jHaTiYuU6MXkHKaZvOkhZVenwQdTnUweS16qRJaeng@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: www-style list <www-style@w3.org>
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>?

> 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.  ¯\_(ツ)_/¯

> 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.

> 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.

> 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...

~TJ
Received on Thursday, 30 June 2016 21:39:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:47 UTC