W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2011

RE: [RequestAnimationFrame] cancelRequestAnimationFrame is an odd name

From: Karen Anderson (IE) <Karen.Anderson@microsoft.com>
Date: Wed, 7 Dec 2011 17:58:04 +0000
To: James Robinson <jamesr@google.com>, Boris Zbarsky <bzbarsky@mit.edu>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <18D01621E7D58B4CA8BA9DDBD0D8B12C037B69DD@TK5EX14MBXC288.redmond.corp.microsoft.com>
I like cancelAnimationFrame too, or some other variety where we don't use "request" as part of the cancel function.  This will align better with the existing naming convention of timers which use [set|clear]API.  I am not sure I have a better "cancel" name either.  Other options I came up with are abort or dismiss, or even cancel as WebDevs are already used to that name.


From: James Robinson [mailto:jamesr@google.com]
Sent: Tuesday, December 06, 2011 9:59 PM
To: Boris Zbarsky
Cc: public-web-perf@w3.org
Subject: Re: [RequestAnimationFrame] cancelRequestAnimationFrame is an odd name

On Tue, Dec 6, 2011 at 8:10 PM, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>> wrote:
The name is a bit odd, if only because it's not really symmetric with requestAnimationFrame.  It took me a bit of staring at it to understand what it might actually mean.

Would it make more sense to call this cancelAnimationFrame?  Or if we want to emphasize that only one request is being canceled, perhaps cancelAnimationFrameRequest?

Either sound fine to me.  The goal is to attempt some sort of symmetry with setTimeout/clearTimeout and setInterval/clearInterval.  I'm not sure if "request"/"cancel" are an ideal pair but I didn't come up with the "request" bit in the first place :).

I think cancelAnimationFrame() would be a solid improvement on the status quo.  Does anyone object to this name?  If not I'll make an edit later this week.  These names are all so long and unwieldy that I'm afraid all libraries and authors will alias them anyway but that ship may have sailed.

- James

Received on Wednesday, 7 December 2011 17:59:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC