Re: [whatwg/dom] Update Event.timeStamp type to DOMHighResTimeStamp. (#420)

majido commented on this pull request.



> @@ -761,15 +764,14 @@ initialized to false.
 the user agent to dispatch an <a>event</a> whose {{Event/isTrusted}} attribute is initialized to
 false.
 
-The <dfn attribute for=Event><code>timeStamp</code></dfn> attribute
-must return the value it was initialized to. When an
-<a>event</a> is created the attribute must be
-initialized to the number of milliseconds that have passed since
-00:00:00 UTC on 1 January 1970, ignoring leap seconds.
-<!-- leap seconds are ignored by JavaScript too -->
+The <dfn attribute for=Event><code>timeStamp</code></dfn> attribute must return the value it was
+initialized to. If available, the attribute should be initialized with the high resolution time of

What do you mean by synthetic events? If you are referring to those constructed in Javascript then that is probably correct and what for example Chrome implementation does. (BTW, I think issue #76 is proposing to make timestamp a constructor argument in which case this is not true anymore)

There may be other implementation related restrictions that makes the precise occurrence time  unavailable. For example on some platforms (e.g., older Windows) there is no cross-process monotonic clock which in browsers with multi-process architecture can mean we cannot use the original timestamp. Or sometimes the driver uses a different clock and timestamp is not reliable. In such cases we end up using the closest estimation we can get. I think falling back to "creation time" is acceptable here too.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/420#discussion_r105285216