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

I find it quite surprising that this is considered an acceptable web-compatible change, for the reasons that @chancancode discussed on the Bugzilla thread.

The jQuery API docs and MDN both define `event.timeStamp` as "The difference in milliseconds between the time the browser created the event and January 1, 1970". Incorrect or not, the practical effect of this is that lots and lots of code exists in the wild that assumes that `new Date()` and `event.timeStamp` can be compared to produce a relative amount of milliseconds.

Of course, `new Date()` and the old `event.timeStamp` are not very reliable as they are not monotonic (I'm very familar with these problems as the author of the RFCs that added [Duration][rust-duration] and [timestamp][rust-time] functionality to Rust)

[rust-duration]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
[rust-time]: https://github.com/rust-lang/rfcs/blob/master/text/1288-time-improvements.md

That said, I am shocked that decoupling the meaning of `event.timeStamp` from `new Date()` is considered even remotely web compatible. Immediate fallout included a demo @chancancode and I happened to be working on for the Ember rendering engine, Angular animation code, and the MSE test suite reported by @foolip.

A more conservative solution to the problem would be to introduce a new attribute (`event.time` as a nice shorter name? `event.performance.timeStamp` for symmetry with `window.performance.*`?).

Given [the kinds of things][fib-hoisting] that have blocked shipping recently for web-compat reasons, and the number of affected properties, I just don't understand how we're full steam ahead here. (In the linked case, the problematic feature had already shipped in IE11 and Edge years earlier, which made the number of affected properties quite small.)

[fib-hoisting]: https://github.com/tc39/ecma262/issues/162

To quote @chancancode:

> By the way, if you are thinking that code that compares against wall-clock time is fundamentally "incorrect", I totally agree with you, and I am personally looking forward to using this feature. However, correctness is irrelevant here because event timestamps have always been tied to wall-clock time, and there are no better way to do this today. The fact is it basically work "good enough" for the majority cases that people have been able to build useful things on top of it today, and we should be careful not to break them. (For example, popular libraries like underscore uses Date.now for debouncing/throttling – while "incorrect", it obviously works "good enough" to be useful in the wild.)

I would quote him in full, but I'd recommend just reading the [linked Bugzilla thread][bugzilla].

[bugzilla]: https://bugzilla.mozilla.org/show_bug.cgi?id=1231619

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