Re: [RequestAnimationFrame] Callback argument should be a callback interface, not just a callback

On Wed, Feb 22, 2012 at 5:43 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 02/23/2012 01:26 AM, Anne van Kesteren wrote:
>
>> On Wed, 22 Feb 2012 18:19:20 +0100, Ms2ger <ms2ger@gmail.com> wrote:
>>
>>> Authors already have to do that, because we won't remove the
>>> functionality from existing APIs.
>>>
>>
>> The few legacy APIs (what besides addEventListener?) are vastly
>> outnumbered by what we are introducing now. That certain legacy APIs use
>> numeric constants is no reason to spread that pattern further either. I
>> do not really see the point in rehashing this argument though. We
>> settled this last year on public-script-coord.
>>
>>
>>
> I don't see where it was really "settled".
> It was discussed, sure.
>
>
>
The other consideration for requestAnimationFrame in particular is that it
is intended to be a drop-in replacement for common uses of setTimeout() and
setInterval() to ease adoption and make it easier to write polyfills.  We
did drop the string form, since it's horrendous, and the arguments
parameter since it is not widely implemented but otherwise
requestAnimationFrame accepts the same type as setTimeout and vis versa.  I
think dropping this in order to match legacy event APIs would be a big
loss.  I've reviewed a lot of sample code, polyfills, and uses of
requestAnimationFrame in the wild and haven't seen any indication that
authors want to use the handleEvent form.

- James