What does "navigationStart" mean as a second argument to performance.measure() in a web worker?

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