Re: [HighResolutionTime2] Add DOMHighResTimeStamp to Event?

Thank you!

A couple things to consider when defining the precise semantics:

1. it's probably worth noting that events won't necessarily arrive in order
of this timestamp (since there could be more latency in the path of some
types than others)

2. the value should be optional for all types of events - eg. so that
synthetically generated events (such as mousemove events that occur in
response to a change onscreen instead of in response to an actual hardware
input) don't need to come up with some fake value that could cause
incorrect results (eg. for some code measuring the velocity of the mouse)

3. in practice a UA may coalesce multiple hardware events into a single DOM
event.  The spec should probably say what the timestamp semantics are in
this case (eg. earliest, latest, average, or omitted).  For use cases like
velocity measurement you really want the timestamp to match the
co-ordinate, so I'd probably say it should be 'latest'.

FWIW we've been discussing these issues briefly in this chromium bug:
https://code.google.com/p/chromium/issues/detail?id=160524

Rick


On Wed, Jan 8, 2014 at 4:25 PM, Jatinder Mann <jmann@microsoft.com> wrote:

>  Looks like we have come full circle. If the DOM Core editor’s suggestion
> was to put it in this spec, let’s try that and see if it makes sense. I’ll
> make spec updates and share.
>
>
>
> Thanks,
>
> Jatinder
>
>
>
> *From:* Rick Byers [mailto:rbyers@google.com]
> *Sent:* Wednesday, January 8, 2014 9:30 AM
> *To:* Jatinder Mann
> *Cc:* public-web-perf@w3.org
> *Subject:* Re: [HighResolutionTime2] Add DOMHighResTimeStamp to Event?
>
>
>
> On Tue, Jan 7, 2014 at 7:33 PM, Jatinder Mann <jmann@microsoft.com> wrote:
>
>  Hi Rick,
>
>
>
> We are actively working on the High Resolution Time L2 spec [1] and this
> is something we could add there. However, seeing that the High Resolution
> Time spec just defines the DOMHighResTimeStamp, and any spec can take that
> definition and use it, it may be more appropriate to specify the Event
> behavior in the DOM Core spec [2]. High Resolution Time L1 is a W3C
> Recommendation [3] so others specs probably won’t mind referencing it. Have
> you talked to the DOM Core editors to see if they will make this change?
>
>
>
> Yes, back in Oct 2012 Anne van Kesteren argued it didn't belong in DOM
> core, but in the high res time spec:
> http://lists.w3.org/Archives/Public/www-dom/2012OctDec/0028.html.
>  Perhaps his opinion will be different now - but it feels like we're going
> in circles here.
>
>
>
> Rick
>
>
>
>  Thanks,
>
> Jatinder
>
>
>
> [1]
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html
>
> [2]
> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-event
>
> [3] http://www.w3.org/TR/2012/REC-hr-time-20121217/
>
>
>
> *From:* Rick Byers [mailto:rbyers@google.com]
> *Sent:* Thursday, December 19, 2013 9:18 AM
> *To:* public-web-perf@w3.org; Jatinder Mann
> *Subject:* [HighResolutionTime2] Add DOMHighResTimeStamp to Event?
>
>
>
> Hi,
>
> Last October there was some agreement [1] that Event should expose a
> DOMHighResTimeStamp, and that it belongs in the HighResolutionTime v2 spec.
>  We removed [2] the hwTimestamp property from the PointerEvent
> specification [3] in preference for this more general mechanism.
>
>
>
> Any update on adding this to the HighResolutionTime2 spec?
>
>
>
> Thanks,
>
>    Rick
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-web-perf/2012Oct/0046.html
>
> [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20220
>
> [3] http://www.w3.org/TR/pointerevents/
>
>
>
>
>
>
>