- From: Arun Ranganathan <arun@mozilla.com>
- Date: Tue, 21 Dec 2010 17:02:32 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Michael Nordman <michaeln@google.com>, Jian Li <jianli@chromium.org>, Ian Hickson <ian@hixie.ch>, Eric Uhrhane <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
On 12/21/10 4:08 PM, Tab Atkins Jr. wrote: > On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathan<arun@mozilla.com> wrote: >> There are more rigid conformance requirements around lastModifiedDate. >> >> http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate > """ > The last modified date of the file; on getting, this MUST return a > Date object [HTML5] with the last modified date on disk. On getting, > user agents MUST create a new Date object with the last modified date > on disk; a different Date object MUST be returned each time. On > getting, if user agents cannot make this information available, they > MUST return null; on getting, even if the user agent could make this > information available on previous gets, if it cannot make this > information available on the current access it MUST return null. > """ > > This is worded really confusingly - there are 4 "on getting"s, and two > of the phrases are just duplicating information expressed in previous > phrases. Can we get something clearer, like this: > > """ > The last modified date of the file. On getting, if user agents can > make this information available, this MUST return a fresh Date object > initialized to the last modified date of the file; otherwise, this > MUST return null. This is a great correction (thanks for supplying good prose!) which I'll gladly make. I agree that it is confusing. -- A*
Received on Tuesday, 21 December 2010 22:03:14 UTC