Originally reported on W3C Bugzilla ISSUE-20511 Mon, 24 Dec 2012 08:26:09 GMT
Reported by Marcos Caceres
Assigned to This bug has no owner yet - up for the taking
For send()'s second argument, the spec says that it takes DOMHighResTimeStamp… however, "DOMHighResTimeStamp" isn't a "real data type" (in that there is no way to actually force a type check on it in some meaningful way AFAICT). Hence, it's actually just a double that is relative to some start time. This is confirmed in [1]:
typedef double DOMHighResTimeStamp;
To avoid confusion during implementation, I would suggest changing the value data type of the second argument of the send() method to a double.
optional double timestamp;
Also, why is the second argument nullable when it's already optional?
Note that the current text in the spec is redundant because WebIDL already handles the type checking. Please remove " or if timestamp is passed but is not a valid DOMHighResTimeStamp, throw a TYPE_ERROR exception".
For send()'s second argument, the spec says that it takes DOMHighResTimeStamp… however, "DOMHighResTimeStamp" isn't a "real data type" (in that there is no way to actually force a type check on it in some meaningful way AFAICT). Hence, it's actually just a double that is relative to some start time. This is confirmed in [1]:
typedef double DOMHighResTimeStamp;
To avoid confusion during implementation, I would suggest changing the value data type of the second argument of the send() method to a double.
optional double timestamp;
Also, why is the second argument nullable when it's already optional?
Note that the current text in the spec is redundant because WebIDL already handles the type checking. Please remove " or if timestamp is passed but is not a valid DOMHighResTimeStamp, throw a TYPE_ERROR exception".
[1] http://www.w3.org/TR/2012/REC-hr-time-20121217/#domhighrestimestamp