(as of May 7)
It's a nice characteristic for high resolution clocks to have sufficient resolution that the difference between two successive readings will always be positive, never zero.
I would love to have the chance to get a DOMHighResTimeStamp not only from the "now" method but also as a property of an ECMAScript event, like event.timeStamp.
It would make sense to fold this into the spec that defines the Performance interface [Navigation Timing].
The spec says that the timer is accurate to at least a tenth of a millisecond, there's hardware that doesn't support that accuracy. It should say to be as accurate as possible, but is not required to be more accurate than a tenth of a millisecond.The spec should call out whether the clock should be ticking while the document is not "fully active" (as defined in HTML).
I would propose to include an additional value stating the timer accuracy which the client can deliver. This would add flexibility and remove unnecessary restrictions, particularly when the delivered accuracy improves as hardware improves.
Should we explicitly state that performance.now() is not affected by visibility?