- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Oct 2015 08:17:02 +0000
- To: public-webtiming@w3.org
ingararntzen has just created a new issue for https://github.com/webtiming/timingobject: == Timestamps in seconds or milliseconds == As it stands now, the StateVector is defined to include timestamps sampled from performance.now(), so the value of .timestamp propverty is expressed in milliseconds. In contrast, velocity and acceleration is expressed in seconds, i.e. unit/second or unit/(second)². This presumably makes more sense for humans. For instance, we are used to media elements measuring offset in seconds, not milliseconds. As a result, there is inconsistency within the state vector with respect to units. Although this is not a problem from a functional perspective, I still think this looks a bit odd, and it could possibly be a source of confusion? The alternative would be for timestamps in the StateVector to be expressed in seconds, not milliseconds, i.e. (performance.now() / 1000.0). A possible downside of this would be that use of vector timestamps with external timing functions, e.g. performance.now(), setTimeout(), setInterval() would require conversion before use. However, having done quite a bit of development with this setup, I don't regard this as much of an issue. So, I'll simply go ahead and change this is the spec, unless someone has a strong opinion about this. See https://github.com/webtiming/timingobject/issues/17
Received on Tuesday, 6 October 2015 08:17:09 UTC