This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This could be useful in some cases. See for example https://github.com/steveblock/web-animations-js/blob/c6023cda75798e748b04e1cda5c6aeb353de92a3/test/testcases/manual-test-preset-timings.html
There's already an issue in the spec for this: http://www.w3.org/TR/web-animations/#the-customeffect-callback-interface I think we shouldn't pass the Player though since we don't want to encourage callback functions to be doing playback control during a call to 'sample'. In the linked-to test case, it would be enough to use the local time of the animation, instead of the current time of the player. I can see this being useful but in the interests of keeping things simple to begin with I'm considering marking this WONTFIX for now and then if we get one or two more use cases for this, REOPENED-ing it and adding the parameter then. What do you think? (Also, I think the other parameters in that method need work--we should probably bundle timeFraction and currentIteration into a SampleTime struct and pass a 'current' SampleTime and a 'previous' SampleTime.)
> I think we shouldn't pass the Player though since we don't want to encourage > callback functions to be doing playback control during a call to 'sample'. Agreed, plus it's easier to get the Player from the Animation than the reverse. > I can see this being useful but in the interests of keeping things simple to > begin with I'm considering marking this WONTFIX for now and then if we get > one or two more use cases for this, REOPENED-ing it and adding the parameter > then. What do you think? OK, sounds good.