- From: VisibleCode via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Apr 2019 18:02:35 +0000
- To: public-css-archive@w3.org
@AmeliaBR wrote: > If we adopt a system where you can directly use SVG path notation, then yes, I would expect some sort of reasonable error handling like that. Fair! > But if we adopt something like the cubic spline syntax, the main question is can a tool like Greensock implement an algorithm to convert (with a reasonable degree of fidelity) their fixed-up path into the standard notation. Yes. @flackr wrote: > We ended up approximating this inverse scale with a generated linear animation with lots of keyframes but it could have been expressed as a single formula. Could supplying a formula solve some of these other express-ability use cases as well? Mostly no. (Though having `calc()` available as an _option_ for easing functions is kind of tempting anyhow.) The problem is many functions don't **have** a (practical) formula representation -- _including functions that result from `cubic-bezier()`'s (ab)use of Béziers!_ The simplest general-purpose solution for representing arbitrary functions (including ones that can't be expressed as formulas) is to use a piecewise polynomial approximation. Piecewise linear (degree 1) is one version of that, but as you discovered needs a lot of keyframes. Piecewise cubic (degree 3), which we're discussing here, is kind of a sweet spot where you don't need that many extra keyframes, but it's still cheap to evaluate and can't go uncontrollably wiggly as can be a problem for degree >= 4. -- GitHub Notification of comment by visiblecode Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/229#issuecomment-488053707 using your GitHub account
Received on Tuesday, 30 April 2019 18:02:38 UTC