- From: Kartikaya Gupta <lists.webapps@stakface.com>
- Date: Thu, 12 Feb 2009 23:35:19 +0000
- To: Darin Adler <darin@apple.com>
- Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Thu, 12 Feb 2009 10:01:44 -0800, Darin Adler <darin@apple.com> wrote: > > Of course, WebKit could change. But I thought the point here was that > the top market share browsers all already agree. I don't see the > upside in changing, given that. Converting the value to a date is > extremely simple. Lets make new APIs use whatever rule we think is > sensible, but I don't see the compelling need to change old, already > interoperable APIs. I'm assuming, perhaps incorrectly, that this is > one of those. > > I agree. I think it makes more sense to leave the ECMAScript binding for Event.timeStamp (and the DOMTimeStamp type in general) a number. I also looked through the HTML5 draft and found the following properties are of type DOMTimeStamp: HTMLTimeElement.date HTMLTimeElement.time HTMLTimeElement.timezone HTMLInputElement.valueAsDate I'm not really sure what the main use cases for these properties are, and whether or not it makes more sense for them to be returned as a number or as a Date in ECMAScript. However, as I suggested before, I think that a new type should be created for those that should return a Date. Cheers, kats
Received on Thursday, 12 February 2009 23:35:56 UTC