ISSUE-13: DOMHighResTimeStamp
event-hrt-attribute
DOMHighResTimeStamp
- State:
- CLOSED
- Product:
- High Resolution Time
- Raised by:
- Jatinder Mann
- Opened on:
- 2014-03-05
- Description:
- [[
Event should expose a DOMHighResTimeStamp, and that it belongs in the HighResolutionTime v2 spec
]]
http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0107.html - Related Actions Items:
ACTION-137 on Philippe Le Hégaret to Follow on with anne on event.systemtime - due 2014-04-30, closed- Related emails:
- Re: Event and DOMHighResTimeStamp (from bbirtles@mozilla.com on 2014-06-12)
- Event and DOMHighResTimeStamp (from plh@w3.org on 2014-06-11)
- Re: {minutes} 2014-04-26 Web Performance Working Group: Resource Priorities, HRT2, Beacon, etc. (from arvind@google.com on 2014-04-05)
- {minutes} 2014-04-26 Web Performance Working Group: Resource Priorities, HRT2, Beacon, etc. (from plh@w3.org on 2014-03-26)
- Re: [agenda] Web Performance WG Teleconference #129 Agenda 2014-03-26 (from plh@w3.org on 2014-03-26)
- ISSUE-13 (event-hrt-attribute): DOMHighResTimeStamp [High Resolution Time] (from sysbot+tracker@w3.org 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?
]]
http://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0001.html
[[
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.
]]
http://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0009.html
[[
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
]]
http://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0019.html
Plan is to update the DOM specification instead
see http://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0013.html
Original commenter is ok
http://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0021.html
Display change log
