RE: ISSUE-7: FrameRequestCallback interface should be designated as Callback=FunctionOnly [Request Animation Frame]

Is there any reason to not allow objects?

DOM Events happen to be one of the most commonly used
interfaces using callbacks. For consistency callbacks should work the  
same way.
(if they don't in geolocation, that could be a bug in that draft.
  geolocation is a bit strange API anyway.)

Supporting objects allows one to easily handle the state related to
callback handling.


Olli



Lainaus "Savil Srivastava" <Savil.Srivastava@microsoft.com>:

> Hi Olli,
>
> It would be helpful if you could provide a scenario where this  
> capability is useful in the context of RequestAnimationFrame.  
> Highlighting how that scenario could not be achieved via  
> FunctionOnly callbacks or why it is more desirable than the  
> FunctionOnly approach would also be much appreciated. This would  
> make it easier to drive a decision (either way).
>
> Thanks,
> Savil
>
> ________________________________________
> From: public-web-perf-request@w3.org  
> [public-web-perf-request@w3.org] on behalf of Cameron McCormack  
> [cam@mcc.id.au]
> Sent: Wednesday, June 01, 2011 3:30 PM
> To: Olli Pettay
> Cc: Web Performance Working Group WG
> Subject: Re: ISSUE-7: FrameRequestCallback interface should be  
> designated  as Callback=FunctionOnly [Request Animation Frame]
>
> Olli Pettay:
>> It is not. In event handling
>> foo.addEventListener("bar_event", { handleEvent: function(e) {}}, true);
>> has proved to be useful.
>
> I don’t know if it has proved to be useful, since it doesn’t really buy
> you much over using a plain Function object, but DOM Events probably
> needs to keep allowing this.  My impression is that new specifications
> tend to use use [Callback=FunctionOnly] more than [Callback].
>
> --
> Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 3 June 2011 15:32:53 UTC