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

On Tue, May 29, 2012 at 12:03 PM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
>> -----Original Message-----
>> From: Pablo Garaizar Sagarminaga [mailto:garaizar@deusto.es]
>>
>> Hello,
>>
>> on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking <jonas@sicking.cc>
>> wrote:
>>
>> > > This is not yet an official last call, but if you'd like to re-read
>> > > the spec and provide additional feedback--this is a good time to do
>> > > it.
>>
>> Disclaimer: I don't know how and where to do this proposal. I hope you'll help
>> me to find the proper place to send it.
>>
>>   During High Resolution Time working draft final call for public comments I
>> wrote a suggestion about DOM events' timestamps and the use of
>> monotonically increasing values provided by High Resolution Time
>> API:
>>
>>   I would love to have the chance to get a DOMHighResTimeStamp as a property
>> of an DOM event, like event.timeStamp. Events'
>> timestamps are also subject to system clock skew and other problems
>> mentioned in High Resolution Time working draft, and providing access to HRT
>> when triggering events will be very helpful to program accurate interactions.
>>
>>   I'm not sure if this could be done adding a new property to the event interface
>> (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp
>> property (i.e., DOMHighResTimeStamp).
>>
>>   It would be great to discuss this feature in future versions of the drafts
>> mentioned before.
>
> I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features:
> 1. The timestamp is relative to the loaded page (not the Unix epoch)
> 2. The timestamp can be in microsecond resolution (a best effort-approach)
> 3. The timestamp is garuanteed to be monotonically increasing.
>
> 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).
>
> 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?

The main value is that it makes it much easier to synchronize the
event with various animations going on. The requestAnimationFrame API
uses high resolution timers relative to the page load time, as does
the performance.now() function. By putting time stamps of the same
unit on events, it's much easier to do things like start animations
when an event occurred, but do all rendering in requestAnimationFrame.
I.e. it makes it easier to account for moving the animated item
between the event occurs and when the rendering happens.

Likewise it makes it easier to do things like hit detection to figure
out where various objects on the screen were when an event occurs,
accounting for partial movement between two rendered frames.

/ Jonas

Received on Tuesday, 29 May 2012 21:55:23 UTC