- From: Pablo Garaizar Sagarminaga <garaizar@deusto.es>
- Date: Wed, 30 May 2012 16:31:02 +0200
- To: Travis Leithead <travis.leithead@microsoft.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps <public-webapps@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, "Philippe Le Hegaret (plh@w3.org)" <plh@w3.org>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Doug Schepers <schepers@w3.org>
Hi Travis, on Tue, 29 May 2012 19:03:49 +0000 Travis Leithead <travis.leithead@microsoft.com> wrote: > Based on #1, we can't simply replace the current timestamp property > on DOM events with a high-resolution time stamp--this would be a > change (though perhaps not very impactful) to backward compatibility. > Therefore, the only plausible action could be a new property (e.g., > "highResolutionTimeStamp" or similar). 100% agree. > However, I wonder what real value this would have. Typically events > only fire within the scope of the current window and do not bleed out > into other windows (Message and Storage events are notable > exceptions)--so new Date() should be self-consistent (coming from the > same script engine) even if other script engines are suffering from > clock-skew. One issue that is present in IE, is Date objects that get > serialized over from Web Workers--they can have a pretty big clock > skew pretty quickly, but hypothetically performance.now() can cover > those scenarios. > Are there other specific use cases that you're finding where the > timestamp property doesn't meet your needs? AFAIK, event.timeStamp is defined when the event is created, not when is dispatched. Thus, using new Date() as the first sentence of the callback function of the event could be problematic for two reasons: 1) If the event queue is not free when the event is created, creation and dispatching timestamps may differ. It would be nice to have both times: the timestamp of the creation of the event, and the timestamp when the event was dispatched. 2) Conversions between UNIX epoch based timestamps in milliseconds and monotonically increasing timestamps relative to the loaded page in microseconds could be tricky considering the former suffers problems that the later solves. As new APIs are adopting these new timestamps, IMHO it would be very positive to have the ability to work with DOM events in a coherent way with them (all monotonically increasing timestamps relative to the loaded page in microseconds). I will prepare the list of cases where this timestamp will be useful as James Robinson suggested. Thank you very much for your time ;-) -- Pablo Garaizar Sagarminaga Universidad de Deusto Avda. de las Universidades 24 48007 Bilbao - Spain Phone: +34-94-4139000 Ext 2512 Fax: +34-94-4139101
Received on Wednesday, 30 May 2012 14:31:49 UTC