ISSUE-13: DOMHighResTimeStamp



High Resolution Time
Raised by:
Jatinder Mann
Opened on:
Event should expose a DOMHighResTimeStamp, and that it belongs in the HighResolutionTime v2 spec
Related Actions Items:
Related emails:
  1. Re: Event and DOMHighResTimeStamp (from on 2014-06-12)
  2. Event and DOMHighResTimeStamp (from on 2014-06-11)
  3. Re: {minutes} 2014-04-26 Web Performance Working Group: Resource Priorities, HRT2, Beacon, etc. (from on 2014-04-05)
  4. {minutes} 2014-04-26 Web Performance Working Group: Resource Priorities, HRT2, Beacon, etc. (from on 2014-03-26)
  5. Re: [agenda] Web Performance WG Teleconference #129 Agenda 2014-03-26 (from on 2014-03-26)
  6. ISSUE-13 (event-hrt-attribute): DOMHighResTimeStamp [High Resolution Time] (from on 2014-03-05)

Related notes:

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?

Philippe Le Hégaret, 5 Mar 2014, 20:55:46

back in Oct 2012 Anne van Kesteren argued it didn't belong in DOM
core, but in the high res time spec: Perhaps
his opinion will be different now - but it feels like we're going in
circles here.

Philippe Le Hégaret, 5 Mar 2014, 20:56:31

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:

Philippe Le Hégaret, 5 Mar 2014, 20:57:24

Plan is to update the DOM specification instead

Philippe Le Hégaret, 13 Jun 2014, 16:23:43

Original commenter is ok

Philippe Le Hégaret, 16 Jun 2014, 12:22:15

Display change log ATOM feed

Yoav Weiss <>, Ilya Grigorik <>, Chairs, Philippe Le Hégaret <>, Xiaoqian Wu <>, Staff Contacts
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 13.html,v 1.1 2019/11/12 07:37:24 carcone Exp $