Re: Need for extended cubic-beziers

Hi Amelia,

Thank you for writing this up! As a high-level comment, I like it! We've
discussed this feature a few times and there's even an issue in the spec 
describing something quite similar to this.[1]

The main resistance, however, has been to the list of numbers in the
syntax. Some were concerned about ease of authoring. My preference was
to introduce this as a lowest common denominator for authoring tools to
use and then layer canned-effects on top later. However, I didn't
succeed in persuading others of that so recently we started working on
an alternative approach.[2]

I have a few specific comments on your proposal below.

On 2015/08/12 7:22, Amelia Bellamy-Royds wrote:
 >         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.

I like this part. I think the previous proposal didn't have this and
authors had to ensure they had the correct number of points.

 >           * 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)

This is probably an example of the sort of markup others were concerned
about.

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

I like this and I know that we toyed with it, but I wonder if it's still
a little hard to hand-author? I had to look at the SVG pictures to work
out what the effect would be.

Is that the purpose? Hand-authoring? Or simply data compression?

We also looked at doing something like a Catmull-Rom curve so you could
specify the peaks of the bounces (rather than control points) but didn't
find a neat representation for that (Catmull-Rom curves don't
necessarily produce functions even if you make x monotonically
increasing).

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

I don't have a strong opinion. I think we need some primitive that lets
you express all the things libraries do. I don't think we want to
reproduce *all* the effects in those libraries but there might be
a couple of effects (particularly bounce/spring effects) that are
sufficiently popular that they deserve their own shorthand syntax.

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

I think this is ok. I think every proposal we've toyed with so far has 
had this restriction.

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

We already have this with step timing functions right? And we have
a rule for determining the result in those cases.

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

I'll defer to others on whether or not this is possible and adviseable
but it would certainly make it easier to read if it were possible.


With all that said, what do you think of the alternative proposal in [2]?

The basic idea is:

* Chain the existing timing functions together specifying the length
   / height of each piece like so:
   cubic-bezier(a,b,c,d) (x, y) cubic-bezier(e,f,g,h) (x2,y2) ...
* You can, of course, include 'linear', 'step-start' etc. in there
* You can leave out the spacing points and they'll be evenly distributed
* You can leave out the timing functions too in which case they'll
   default to linear

I don't know how you're supposed to create smooth joins between
curves with this approach but I believe there was a proposal around
that. Shane and others can probably better remember the finer details
that aren't captured in [2].

Best regards,

Brian

[1] http://w3c.github.io/web-animations/#issue-9e5dcac9
[2] https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0104.html, 
item 4

Received on Wednesday, 12 August 2015 06:43:24 UTC