- From: Philippe Le Hégaret <plh@w3.org>
- Date: Thu, 15 Dec 2016 14:57:28 -0500
- To: Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On 12/15/2016 3:21 AM, Boris Zbarsky wrote: > 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? You cannot have a PerformanceMark using the "navigationStart" in non-Worker case. The spec says to throw a SyntaxError if you try to create one. It doesn't say that for Workers however and I don't think we should enable 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>. I guess we should link to how PerformanceMarks get created instead of the interface definition but that wouldn't be enough to address your issue. > 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. Yes and we "lost" it from the spec after we started to deprecate the PerformanceTiming interface. This was a mistake obviously. But, imho, we shouldn't include Workers from the behavior. I need to make sure the spec takes this into account and allows cover the tests in: https://w3c-test.org/user-timing/test_user_timing_measure_exceptions.html > 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. You're correct that this is not clear and I don't think we considered the case of Workers. The goal is to deprecate PerformanceTiming overtime and we don't expose it to Workers on purpose. In addition, the "trick" of having predefined marks by reusing attribute names triggers a whole set of additional questions for future extensions that we'd rather avoid. So, you asked what "navigationStart" means as a second argument to performance.measure() in a web worker. In this case, unless you did explicitly create a PerformanceMark object with that name, it would throw a SyntaxError... which isn't writing down in the spec. > 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. The primer needs a refresh since we abandoned specs like FRAME-TIMING and SERVER-TIMING. Having said that, the first problem here is that I did cut off too much of the original User Timing specification, making the current draft unhelpful and broken. Regarding the broken links, I've been unhappy for a while with the lack of proper linking system/tracker. We updated our specs to the new WebIDL syntax ... but we left that part out of the editor draft. In summary, I need to raise a bunch of issues against the spec but feel free to beat me to it. > 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. I agree we have an interdependencies issue but this is not just limited to the perf specs imho. We link to a bunch of other specs as well and don't track those dependencies well. I've been meaning to explore whether some of the tooling used in the webrtc specs would help us on that front but reality didn't allow me to spend time on this front lately :( Philippe
Received on Thursday, 15 December 2016 19:57:38 UTC