- From: Tony Gentilcore <tonyg@google.com>
- Date: Wed, 10 Nov 2010 08:32:29 -0800
- To: Sylvain Hellegouarch <sh@defuze.org>
- Cc: Anne van Kesteren <annevk@opera.com>, Zhiheng Wang <zhihengw@google.com>, Jonas Sicking <jonas@sicking.cc>, public-web-perf <public-web-perf@w3.org>
We discussed naming/location on a previous call. IIRC, here were the points we came to (others please keep me honest here): - Hang it under console? The goal of the performance object is to expose information to the DOM in production. This is distinct from console which only interacts with the debugging console during development. - Hang it under document? There are subtle differences between window and document lifetimes (for instance a late document.write can replace the document). The performance information outlasts a document, so it didn't make a whole lot of sense there. However, I don't recall any strong objections to moving it if we want to revisit. - Will global performance conflict with many sites? We discussed allowing it to be replaceable so that if a site were to define var performance or window.performance, it would override the built-in. This would mitigate all but the most pathological conflicts. Unfortunately, I don't recall where we ended up on this discussion and can't find anything one way or the other in the spec. Another alternative which I don't think we discussed would be to hang them directly under navigator. e.g. navigator.timing, navigator.navigation... -Tony On Wed, Nov 10, 2010 at 2:20 AM, Sylvain Hellegouarch <sh@defuze.org> wrote: > > > On Wed, Nov 10, 2010 at 11:16 AM, Anne van Kesteren <annevk@opera.com> > wrote: >> >> On Wed, 10 Nov 2010 07:11:25 +0100, Jonas Sicking <jonas@sicking.cc> >> wrote: >>> >>> One solution would be to stick it on the document object. Another to >>> come up with a more exotic name though I have to admit any good >>> suggestions escape me at the moment. >> >> One idea I had was to put it on window.console if we are going to >> standardize parts of window.console anyway since the performance API is >> mostly for debugging and figuring out what is going on. >> > > > Most likely indeed. However, I was wondering if it would make sense to use > the performance API as a monitoring platform in production as well. It could > offer some interesting pieces of information. Mind you, I'm not familiar > with its impact on the resource processing itself. > -- > - Sylvain > http://www.defuze.org > http://twitter.com/lawouach >
Received on Wednesday, 10 November 2010 16:33:41 UTC