Bug 45761 – Don't clamp cubic-bezier timing functions between 0 and 1

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Simon Fraser (smfr)]

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

[Dean Jackson]

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.

[Simon Fraser (smfr)]

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.

[Peter Beverloo]

Created attachment 107476 [details]
Patch

[Simon Fraser (smfr)]

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?

[Lea Verou]

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

[Peter Beverloo]

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

[Dean Jackson]

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.

[Dean Jackson]

ping?

[Peter Beverloo]

I'll post an updated patch tomorrow, apologies for the delay.

[Peter Beverloo]

Created attachment 109026 [details]
Patch

Updated patch. This adds tests for SVG Lengths, colors, shadows and transforms.

[Dean Jackson]

I filed https://bugs.webkit.org/show_bug.cgi?id=69032 to make sure the Safari CoreAnimation ports still work after this change.

[WebKit Review Bot]

Comment on attachment 109026 [details]
Patch

Clearing flags on attachment: 109026

Committed r96276: <http://trac.webkit.org/changeset/96276>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Dean Jackson]

My fault, but we should still clamp the X coordinate values.