W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

Re: DOMHighResTimeStamps in DOM events, use cases

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 10 Oct 2012 12:09:45 -0400
Message-ID: <50759DC9.5020901@mit.edu>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Robert Flack <flackr@chromium.org>, Pablo Garaizar Sagarminaga <garaizar@deusto.es>, www-dom@w3.org, Jonas Sicking <jonas@sicking.cc>
On 10/10/12 6:31 AM, Anne van Kesteren wrote:
> I'm not quite sure I follow. I guess the main problem would be that
> you suddenly have a decimal in there which is not what everyone
> expects at the moment. Boris, Jonas, opinions? (Context is whether or
> not we should have a new attribute on events indicating when the
> system dispatched them or if we should just change Event.timeStamp.)

The only relevant comment I have is that at one point Gecko temporarily 
tried making Date.now() return sub-millisecond times, with a decimal. 
This broke things all over that were concatenating the return value of 
Date.now() with some constant strings to produce things like "unique" 
class names and whatnot.  Turns out once your class name contains a '.' 
you have to be careful with your CSS.  ;)

Anyway, there is probably nonzero risk of this being a problem with 
Event.timeStamp.  Not sure how high the risk is.

The other possible risk is that high-res time and current 
Event.timeStamp have a different 0 point, right?

> So would Event.systemTime be time since epoch as well? I cannot
> actually find an exact definition anywhere in the previous emails and
> I'm not sure what
> document()->loader()->timing()->convertMonotonicTimeToZeroBasedDocumentTime()
> does ;-) (I asked on #webkit, but people were asleep.)

Presumably converts to time with 0 set to document load start.  So the 
same timescale as performance.now().

Received on Wednesday, 10 October 2012 16:10:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:01 UTC