W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [whatwg] DOMTimeStamp binding

From: Kartikaya Gupta <lists.webapps@stakface.com>
Date: Thu, 12 Feb 2009 15:12:49 +0000
To: "Simon Pieters" <simonp@opera.com>
Cc: "Darin Adler" <darin@apple.com>, whatwg@whatwg.org, public-webapps@w3.org
Message-ID: <E1LXdM4-0004WQ-UE@bart.w3.org>

On Thu, 12 Feb 2009 07:03:22 +0100, "Simon Pieters" <simonp@opera.com> wrote:
> On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta <lists.webapps@stakface.com> wrote:
> > I updated to Safari 3.2 on Windows (which looks it also has WebKit  
> > 525.27.1) and you're right, it is now showing "number" instead of  
> > "object". I guess this was changed not too long ago. So then my question  
> > is: why was it changed? And seeing as Opera, WebKit, and Gecko are in  
> > agreement now to return a number rather than a Date in ECMAScript, will  
> > the DOM 3 Core spec be updated? Or will this get rolled into Web DOM  
> > Core and/or HTML5?
> Right now Web DOM Core says:
>    A DOMTimeStamp represents a number of milliseconds. 
>       typedef unsigned long long DOMTimeStamp;
> ...and then refers to WebIDL for what that means to ECMAScript.

It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually return Date objects like the HTMLInputElement.valueAsDate in HTML5. This is likely what I'll end up doing for our IDL files anyhow so that all the bindings get generated correctly.

Received on Thursday, 12 February 2009 15:20:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:24 UTC