Re: [csswg-drafts] [css-timing-2] Complex timing functions (#229)

>  previously proposed to www-style by @AmeliaBR.

I'd kind of forgotten about that. I'd definitely forgotten that I'd made nice figures to go with it. It would probably be helpful if they were copied over here.  Pulling out the key points [from my August 2015 proposal](https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0037.html) here, with some updated links.

-----------------------------------

Make  the definition of [cubic Bézier curves](https://drafts.csswg.org/css-easing/#cubic-bezier-easing-functions):

> A cubic Bézier curve is defined by a series of control points, P0 through Pn (see [the figure] for an example where n=4). P0 and Pn are always set to (0,0) and (1,1), respectively. The parameters to the easing function are used to specify the values for points P1 to Pn-1. These can be set to preset values using the keywords listed below, or can be set to specific values using the cubic-bezier() function. In the cubic-bezier() function, each point Pi is specified by both an X and Y value.

Then farther down, the syntax and definition of the cubic-bezier function is replaced as follows:

>      cubic-bezier([<number>, <number>]*)
> 
> Specifies a cubic-polybezier curve. Each pair of values specifies a point Pi in the form x1,y1; an odd-numbered sequence of values is invalid. All x values must be in the range [0, 1] and each x value must be equal to or greater than the previous; otherwise, the definition is invalid. The y values are unrestricted.
The series of points is converted to a series of connected cubic Bézier curve segments by grouping into sets of three: two control points followed by a vertex point. If the number of points (plus the implicit 1,1 end point) is not a multiple of three, the sequence is padded with the point 1,1 to create complete cubic Bézier segments.
> 
> For example,
> -  A cubic-bezier function with no parameters is equal to cubic-bezier(1,1, 1,1), which is essentially a linear timing function.
> - The ease-in function could also be written as cubic-bezier(0.42,0).
> - A multiple bounce transition could be written as follows, resulting in the curve visualized in [Figure]:
>   
>          cubic-bezier(0.25,0.25, 0.25,0.75, 0.3,1,
>                       0.5,0.5, 0.6,0.5, 0.7,1,
>                       0.85,0.8 0.9,0.8)
![A line graph from x=0 to 1 and y=0 to 1, where the line starts at (0,0), rises in an exponential-like curve until it reaches y=1, then sharply bounces back down to around y=0.6 for x= approximately 0.5, turns and hits y=1 again, then another smaller bounce until it ends at (1,1).](https://lists.w3.org/Archives/Public/public-fx/2015JulSep/att-0037/timing-functions-bounce.svg)

Finally, a new function could be added to make it easier to make smooth curves: 

>    smooth-cubic-bezier([<number>, <number>]*)
> Specifies a cubic-polybezier curve with automatically-calculated smooth connections between segments. Each pair of values specifies a point Pi in the form (x1, y1); an odd-numbered sequence of values is invalid. All x values must be in the range [0, 1], each x value must be equal to or greater than the previous; otherwise, the definition is invalid. The y values are unrestricted.
> 
> If there are 1 or 2 pairs of values provided, the result is the same as for the cubic-bezier function.  For 3 or more points, an implicit control point is inserted after every vertex point, that is equal to that vertex point plus the vector from the previous control point to that vector point.  The remaining explicit points therefore alternate between control points and vertex points.  Again, the sequence of points is padded with 1,1 if necessary to make complete cubic Bézier segments.
>
> For example, the following two functions specify the same curve:
>
>     smooth-cubic-bezier(0,0.75, 0,1, 0.5,0.5)
>     cubic-bezier(0,0.75, 0,1, 0.5,0.5, 1,0, 1,1)
>
> Both result in the curve visualized in [Figure]
![A line graph from x=0 to 1 and y=0 to 1, where the line starts at (0,0), rises steeply as x increases, then slides back down before rising again, symmetrically, to (1,1).](https://lists.w3.org/Archives/Public/public-fx/2015JulSep/att-0037/timing-functions-smooth.svg)

A first approximation at the figures are attached; if you want to play around quickly, you can also fork from https://jsfiddle.net/L1o71c1c/1/  Or, you know, write a script to generate the SVG markup automatically from a function specification.

Things to discuss: 

Given these definitions, should new pre-defined functions be introduced to represent bounce/elastic timing functions in popular JS libraries?

Is the restriction on x values appropriate? We need to ensure that the final curve is a proper function, with each x value having a single corresponding y value.  Forcing vertex and control points to be in sorted x order should ensure this, but may be overly restrictive.

It is nonetheless possible to draw a completely vertical arc segment with the current wording.  We could address this by adding another restriction (the x values for vertex points must be strictly greater, not just greater or equal to) or we could add an interpretation rule (apply the maximum value, consistent with how the steps function works).

Are the commas between every number in the cubic-bezier function necessary?  Do current implementations enforce that syntax?  Compare with (a) the Shapes spec which requires commas between points in a polygon, but does not allow them between x y pairs, and (b) SVG syntax, which allows commas and whitespace interchangeably, so many people with mathematical background use commas to join x y pairs and whitespace to separate them, like x1,y1 x2,y2.

[Note that there were comments on the proposal at the time from [Brian Birtles](https://lists.w3.org/Archives/Public/public-fx/2015JulSep/0038.html), including a link to an even older proposal, that I'll copy into a separate comment to get everything in one place.]

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/229#issuecomment-484309283 using your GitHub account

Received on Thursday, 18 April 2019 00:22:54 UTC