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

> It seems unlikely other vendors will ship something fast, given #23 (comment) and #23 (comment), maybe the best approach here is to just wait it out a bit and see what actually happens.

Actually @rniwa didn't say anything about the priority they'd give to landing a new API in WebKit here. @rniwa thoughts?

Note that with [passive event listeners](https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md) now shipping, we're starting to actively encourage the [measurement of scroll latency](http://rbyers.net/scroll-latency.html) using this API.  But all our examples will show a pattern that works for both the WebKit and blink implementations (the only two implementations today exposing the original driver time), so it'll probably still be possible for us to switch back to the WebKit behavior in the future without causing too much disruption (it'll just introduce the NTP skew problem in scenarios that were previously more stable in Chrome, but we don't know how bad that tends to be in practice).

So if collecting more data on the impact in Chrome over a few months would be valuable to this debate, then that's fine with me.  But if no amount of such additional data would change other implementor's minds then there's no benefit to waiting.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/23#issuecomment-215442556