- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 15 Dec 2016 03:21:33 -0500
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Say I am a hypothetical (not so much) implementor trying to figure out what should be done with "navigationStart" as the second argument to a performance.measure() call. What should be done with it? I guess we start in https://w3c.github.io/user-timing/ (which is helpfully not linked from <https://www.w3.org/TR/user-timing/>). This says: If startMark is omitted, let start time be 0. Otherwise let start time be the value of the startTime attribute from the most recent occurence PerformanceMark object in the performance entry buffer whose name matches value startMark. Ignoring the missing "of" after "occurence" [sic; spelling], what does this actually mean? How would a PerformanceMark object with such a name end up in the buffer? Would it? Following the link to https://w3c.github.io/user-timing/#dom-performancemark is a bit non-obvious, but it has a link to <https://w3c.github.io/performance-timeline/#dfn-performance-timeline>. Following the link to https://w3c.github.io/performance-timeline/#dfn-performance-entry-buffer lands is in more or less the same place. It defines a way to queue things, but there's no way to figure out what calls those things. OK, so I went through all the things linked from https://w3c.github.io/perf-timing-primer/ and looked for "PerformanceMark". Oops, this only links to TR/user-timing, not the editor's draft. OK, if I fix that, and assume that TR/server-timing is not relevant, then the only mention of "PerformanceMark" is in user-timing. So there is no such PerformanceMark unless I earlier did mark("navigationStart"). Of course in that case start time isn't even defined by this draft. Incidentally, if I look at https://www.w3.org/TR/user-timing/#dom-performance-measure then it explicitly says, for the second argument: May be the name of one of the attributes in the PerformanceTiming interface [Navigation Timing]. In this case, the value of that attribute is used as the start DOMHighResTimeStamp time value. But this is all dating to back before Performance was exposed to workers. In particular, PerformanceTiming is _not_ exposed to workers, so it's not clear how this should work in the worker world, exactly. -Boris P.S. I'm still generally quite frustrated with the way the modularization of these specs was done and the resulting impossibility of actually tracking anything down in all the broken links and unexplained dependencies. The primer was supposed to theoretically help, but in practice it's useless because it too has broken links. Since in practice all these specs are having to be evolved in lockstep anyway because of interdependencies as far as I can tell, I strongly feel that they should just be a single spec. That will at least make the interdependencies clear instead of hiding them.
Received on Thursday, 15 December 2016 08:22:19 UTC