W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

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

From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
Date: Thu, 18 Apr 2019 00:28:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-484310242-1555547287-sysbot+gh@w3.org>
Proposal for "Stacked Timing Functions" from (I think) a face-to-face breakout session in May 2015, as [sent to the fx mailing list in June 2015](https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0104.html) by @birtles.

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

 STACKED TIMING FUNCTIONS
===========================

* Stacked timing functions would allow you to emulate the effect of
   nested groups.
* However, Brian points out that chained timing functions have the same
   ability to emulate arbitrary easings, and are also more accessible and
   more widely applicable - e.g. to produce spring-like easings.

We worked on a syntax for chained timing functions and came up with:

    easing: [ tf? point? ]?

Concretely, easings look like

    easing: cubic-bezier(a,b,c,d) (x, y) cubic-bezier(e,f,g,h) (x2,y2) ...

You can leave out the points (they're evenly distributed between
provided points, where easings always start at (0,0) and end at (1,1).

You can leave out the timing functions (in which case they'll default to
linear).

cubic-bezier parameters are always in global (0,0,1,1)-space. This means
that you can accidentally provide erroneous easings, e.g.:

    easing: cubic-bezier(0.2, 0.8, 0.6, 0.6) (0.5, 0.3) cubic-bezier( 0.6, 0.9, 0.7, 1.0)

Here the first point has an x coordinate that is less than the second
x control point of the first bezier (0.5 < 0.6). Concretely, an easing
is OK as long as *all* of the x coordinates (specified and inferred) are
in [nondescending== increasing](http://mathworld.wolfram.com/IncreasingFunction.html) order.

So this is incorrect too, although it's hard to see why:

    easing: cubic-bezier(0.2, 0.8, 0.6, 0.6) cubic-bezier( 0.6, 0.9, 0.7, 1.0)

becomes:

    easing: cubic-bezier(0.2, 0.8, 0.6, 0.6) (0.5,0.5) cubic-bezier( 0.6, 0.9, 0.7, 1.0)

(because that's what easing: linear linear would do)

We could instead infer point x coordinates to be evenly spaced between
adjacent specified x coordinates, which would mean that the above would
be equivalent to

    easing: cubic-bezier(0.2, 0.8, 0.6, 0.6) (0.6,0.5) cubic-bezier( 0.6, 0.9, 0.7, 1.0)

which is actually fine. But if we're doing that, should we do the same
thing for the y coordinate?

    easing: cubic-bezier(0.2, 0.8, 0.6, 0.6) (0.6,0.75) cubic-bezier( 0.6, 0.9, 0.7, 1.0)

 > Google to polyfill this. If it's good then we'll add something to L2.


-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/229#issuecomment-484310242 using your GitHub account
Received on Thursday, 18 April 2019 00:28:10 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:07 UTC