W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: DOM3 Events - additional editing help to move the spec forward

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>
Message-ID: <20120530163102.514747e8@argon>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT