From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>

Date: Tue, 11 Aug 2015 16:22:25 -0600

Message-ID: <CAFDDJ7ybOZh1BcYZO-rjPKM4O7ED5kry=F5d6w-97sBW_bk3mQ@mail.gmail.com>

To: "public-fx@w3.org" <public-fx@w3.org>, "L. David Baron" <dbaron@dbaron.org>, Rachel Nabors <rachelnabors@gmail.com>

Received on Tuesday, 11 August 2015 22:22:54 UTC

Date: Tue, 11 Aug 2015 16:22:25 -0600

Message-ID: <CAFDDJ7ybOZh1BcYZO-rjPKM4O7ED5kry=F5d6w-97sBW_bk3mQ@mail.gmail.com>

To: "public-fx@w3.org" <public-fx@w3.org>, "L. David Baron" <dbaron@dbaron.org>, Rachel Nabors <rachelnabors@gmail.com>

Concrete proposal to start the discussion. Implementors, does this seem feasible? Authors, does the extra complexity seem proportional to the extra functionality? In section 2.3 of the CSS Transitions spec [1], replace the paragraph after Figure 2 with the following: A cubic Bézier curve <http://en.wikipedia.org/wiki/B%C3%A9zier_curve#Cubic_B.C3.A9zier_curves> is defined by a series of control points, P0 through Pn (see Figure 3 for an example where n=4). P0 and Pn are always set to (0,0) and (1,1), respectively. The transition-timing-function <https://drafts.csswg.org/css-transitions/#propdef-transition-timing-function> property is 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() <https://drafts.csswg.org/css-transitions/#funcdef-cubic-bezier> function. In the cubic-bezier() <https://drafts.csswg.org/css-transitions/#funcdef-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> <http://dev.w3.org/csswg/css-values-3/#number-value> , <number> <http://dev.w3.org/csswg/css-values-3/#number-value>]*) <https://drafts.csswg.org/css-transitions/#funcdef-cubic-bezier>Specifies a cubic-polybezier curve <http://en.wikipedia.org/wiki/B%C3%A9zier_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 setments. 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) Finally, a new function could be added to make it easier to make smooth curves: smooth-cubic-bezier([<number> <http://dev.w3.org/csswg/css-values-3/#number-value>, <number> <http://dev.w3.org/csswg/css-values-3/#number-value>]*) <https://drafts.csswg.org/css-transitions/#funcdef-cubic-bezier>Specifies a cubic-polybezier curve <http://en.wikipedia.org/wiki/B%C3%A9zier_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 first approximation at the figures are attached; if you want to play around quickly, you can also fork from http://fiddle.jshell.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. [1]: https://drafts.csswg.org/css-transitions/#transition-timing-function-property

(image/svg+xml attachment: timing-functions-smooth.svg)

(image/svg+xml attachment: timing-functions-bounce.svg)

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 19:49:54 UTC
*