- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 10 Oct 2012 12:09:45 -0400
- 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(). -Boris
Received on Wednesday, 10 October 2012 16:10:18 UTC