Re: [dom] High resolution timing for events (#23)

BTW, I also looked at the ```that.startTime = e.timeStamp || Date.now();``` usage pattern mentioned [earlier](https://github.com/whatwg/dom/issues/23#issuecomment-180697240).

This pattern is workaround for a Firefox bug where the timestamp for **some** events (most notably animation/transition events) can be 0. (I believe this issue is getting fixed in Firefox in conjunction with switching the timeStamp to high-res time value but @birtles is the expert). Some notes:
 - The workaround is only ever useful in Firefox.
 - The workaround allows the animation/transition events timestamp to become comparable to Date.now() [Note 1].
 - The workaround does not make timestamp of any other event (notably input events [Note 2])  
   comparable with Date.now().

The workaround is useful for animation/transition events but it is otherwise fragile and prune to bug 
if indiscriminately used on all events. It will not protect code that blindly compares 
event.timeStamp to Date.now() for all event types. 

Looking at the linked [iscroll-lite.js](https://github.com/cubiq/iscroll/blob/v4/src/iscroll-lite.js#L207), the library is using the above workaround on input events which is incorrect :-1: but fortunately they only compare  ```startTime``` to other event.timestamp values and never to Date.now():+1:. So despite using the workaround unnecessarily (incorrectly?) the code actually works fine and should not be impacted by switching to ```DOMHighResTimeStamp```.


Note 1: This is the Angular css-animation usage pattern which was impacted by the switch. 
Note 2: In Firefox, input events do get a non-zero timeStamp with a system startup timebase that is incompatible with Date.now(). 
        So for input events, this workaround is not actually exercised and if the code ever tries to compare an input event timeStamp 
        with Date.now() it breaks.



---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/23#issuecomment-184707180