|Summary:||Don't clamp cubic-bezier timing functions between 0 and 1|
|Product:||WebKit||Reporter:||Simon Fraser (smfr) <simon.fraser>|
|Component:||CSS||Assignee:||Peter Beverloo <peter>|
|Severity:||Normal||CC:||cmarrin, dino, lea, mathias, noam, paulirish, peter, webkit.org, webkit.review.bot|
|Version:||528+ (Nightly build)|
Description Simon Fraser (smfr) 2010-09-14 10:02:43 PDT
See <http://lists.w3.org/Archives/Public/www-style/2010Apr/0489.html> <http://lists.w3.org/Archives/Public/www-style/2010Jun/0254.html> we decided that it was OK to not clamp the bezier functions (in one direction, at least).
Comment 1 Dean Jackson 2010-09-15 18:30:32 PDT
I think we should add some new timing functions at the same time. When people want a cubic to extend beyond [0,1] they are most likely doing some kind of bounce effect. It would be much more author friendly to have timing-function: bounce-in, maybe with a parameter that says the number of bounces.
Comment 2 Simon Fraser (smfr) 2010-09-15 19:33:27 PDT
I think we should add more timing functions, but as a later step. We should survey the JS libraries to get a feel for what interesting functions are.
Comment 4 Simon Fraser (smfr) 2011-09-15 09:15:39 PDT
Comment on attachment 107476 [details] Patch With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled?
Comment 5 Lea Verou 2011-09-15 09:18:27 PDT
(In reply to comment #4) > (From update of attachment 107476 [details]) > With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled? Judging by how other browsers handle it, it only exceeds the range when the exceeding values make sense. For example, animating from a color to an edge RGB color like blue or fuchsia won't produce any bounce, because values above 255 are invalid.
Comment 6 Peter Beverloo 2011-09-15 09:40:54 PDT
(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 107476 [details] [details]) > > With this change, isn't it possible to now exceed the start/end range for an animating value? How is that handled? > > Judging by how other browsers handle it, it only exceeds the range when the exceeding values make sense. For example, animating from a color to an edge RGB color like blue or fuchsia won't produce any bounce, because values above 255 are invalid. Correct. An animation from #555 to #CCC which bounces might touch #DDD (or even #FFF if the bounce is big enough), but will be clamped thereafter. As expected, white will remain white and black will remain black; the same applies to other colors. Transforms (e.g. rotating ones) overshoot slightly prior to moving back. One exception here are shadows, as they cannot transition between normal and inset ones (thus cannot bounce as such either) yet.
Comment 7 Dean Jackson 2011-09-15 13:19:49 PDT
Comment on attachment 107476 [details] Patch Could you add a test that makes sure values are clamped? ie. animate colors. Unfortunately our hacky test-helping library doesn't really support colors that well. I added something like it in the test for transitions on SVG properties. Also, it's not clear what effect this will have on hardware animations using Core Animation. I'll have to check. r- just because I think we have to exercise the clamping now that it is possible to produce values outside the normal bounds.
Comment 8 Dean Jackson 2011-09-27 14:47:19 PDT
Comment 9 Peter Beverloo 2011-09-27 14:47:58 PDT
I'll post an updated patch tomorrow, apologies for the delay.
Comment 10 Peter Beverloo 2011-09-28 08:53:39 PDT
Created attachment 109026 [details] Patch Updated patch. This adds tests for SVG Lengths, colors, shadows and transforms.
Comment 11 Dean Jackson 2011-09-28 14:59:46 PDT
I filed https://bugs.webkit.org/show_bug.cgi?id=69032 to make sure the Safari CoreAnimation ports still work after this change.
Comment 12 WebKit Review Bot 2011-09-28 17:28:17 PDT
Comment on attachment 109026 [details] Patch Clearing flags on attachment: 109026 Committed r96276: <http://trac.webkit.org/changeset/96276>
Comment 13 WebKit Review Bot 2011-09-28 17:28:22 PDT
All reviewed patches have been landed. Closing bug.
Comment 14 Dean Jackson 2013-01-08 12:31:22 PST
My fault, but we should still clamp the X coordinate values.