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

@birtles:

> @wycats: @bzbarsky, @annevk and I discussed this in February this year and I think @bzbarsky in particular had a preference for adding another eventTime or time member given the compatibility concerns.

I wish this was shared earlier. All other signals so far has been that Firefox is on-board with
the plan to experiment and ship if we don't find a non-trivial compat issues. In fact originally
we were [happy to wait](https://bugzilla.mozilla.org/show_bug.cgi?id=1026804#c8) for Firefox to ship and report on compat issue before we go ahead. 

@rniwa:
> > However, since then Chrome has shipped with reportedly few issues so I was under the impression that this was proving to be Web-compatible and the extra member was not required.

Well the list of reported issues is essentially the same as [before](https://github.com/whatwg/dom/issues/23#issuecomment-184702178) even after being in Chrome stable (on all platforms) for the past 6 weeks. IMHO this is very good evidence. Moreover the result matches our expectation based on the [httparchive data analysis](https://github.com/whatwg/dom/issues/23#issuecomment-181518064) we did before launch which is another good signal.


> The very fact YouTube had to workaround this and Angular had to have a fix is a good indication that this change is not Web compatible. Just the issues listed in #23 (comment) are enough indication to us that we can't make this change in the foreseeable future.

We have expected some web-compat issues all along, the question has always been the scale and the impact of such issues. We have attempted to get a sense of this by using httparchive and carefully monitoring beta, dev channels before launch and have continued this after going to stable.


On YouTube case: They had an existing workaround for Firefox edgecases which works
well for Chrome recent changes as well. So they haven't done any modification in response to a breakage.
So there was no modification or impact.

On Angular CSS Animation module: The scale and impact is quite low here. See detailed
description of the issue. Happy to debate my evaluation of impact though.

@wycats:

Thanks for the writing [this](https://github.com/whatwg/dom/issues/23#issuecomment-214934566) up. It is a good summary of differences between browsers and main 
workarounds being used. I have some notes though:

> for many events, the timeStamp is (interoperably) either the same as new Date() (as required by DOM3 and DOM4) or 0 (as allowed by DOM2).

I have an [fairly accurate list](https://github.com/whatwg/dom/issues/23#issuecomment-186004726) of the Firefox behaviour. It is a mixed bag. For many events this is not true (including almost all input events):
mouse, wheel, key, touch, click events, hashchange, popstate, any custom events


> It's easy to observe that developers expect the result of e.timeStamp to return a value that 
looks like a JavaScript date, because date.setTime(e.timeStamp) is very common.

It is actually very hard to get any reasonable signal from the above github search.
I looked at the first 10 pages. Lots of false positive (timestamp not related to any event) and
mostly dominated by a single [code snippet](https://github.com/cavemankent/firstpractice/blob/98fea70642307951641898bc9b4ec86ff5750167/c07/js/event-object.js) from a tutorial set. Not really indicative of any real usage.


>  any developer in the past who wanted to compare a timestamp to a fixed timestamp had no choice but to compare to Date.now(), and that code is both reasonable and often not very easy to fix. 

This is rather trivial to fix actually. (Use Date.now() in event handler than timestamp)
Also how big of a usecase is this? Our httparchive search shows it is rather small.
Finally this pattern has subtle [bugs](https://github.com/whatwg/dom/issues/23#issuecomment-181579384) and not very dependable even after Firefox workaround.

> The TLDR is that until Chrome decided to make this change, the DOM spec had been increasing in precision, and browsers were coming into compliance.

Coming into compliance since 2011 (DOM3) and we still don't have that. This is what worries me 
about introducing yet another timestamp attribute with a slightly different semantic. Now we will have two slightly in compliance values to take care an push forward in the platform not to mention the burden that it has on API complexity and long-term simplicity of the platform.

It is this option that we have to weigh against web-compat issues. Compat issues that our data so
far suggests them to be small in scale, easy to fix, low impact, and subtly broken already. We still have a good chance to make the switch without incurring the cost of two timestamp attributes.

Finally, from Blink side we are happy to follow up with any new consensus on this issue. We have
been active in pursuing this and have tried to help reach a reasonable inter-operable solution in
good faith :).

---
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-215123846