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

RE: [AnimationRequestFrame] Initial editor's draft of AnimationRequestFrame spec available

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 4 May 2011 01:33:02 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B04068339E2@TK5EX14MBXC252.redmond.corp.microsoft.com>
Yes, my point is that the spec should capture our desired behavior in some form. 

I understand that a browser may not be able to guarantee that a callback will occur. So we should either specify as normative text that a user agent must attempt to match the number of callbacks with the refresh rate of the display, or specify as non-normative text that a user agent should match the number of callbacks with the refresh rate of the display. My preference is the former.

Jatinder 

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Boris Zbarsky
Sent: Tuesday, May 03, 2011 6:30 AM
To: public-web-perf@w3.org
Subject: Re: [AnimationRequestFrame] Initial editor's draft of AnimationRequestFrame spec available

On 5/3/11 1:08 AM, James Robinson wrote:
> The words "normative" and "should" are mutually exclusive.  I agree 
> that browser should (and likely will, regardless of what we do) 
> schedule these callbacks to match the refresh rate of the display 
> whenever possible, but text in a specification that uses the word "should"
> instead of "must" is by definition not a normative requirement.  We 
> can't always promise that the callbacks will be invoked at the refresh 
> rate of the display and so I feel this is a quality of implementation issue.

I think Jatinder's point is that the spec needs to make it clear that firing at the refresh rate is the desired behavior for this API.

-Boris
Received on Wednesday, 4 May 2011 01:33:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 4 May 2011 01:33:31 GMT