- From: Anderson Quach <aquach@microsoft.com>
- Date: Fri, 7 Jan 2011 18:33:32 +0000
- To: Tony Gentilcore <tonyg@google.com>, Patrick Meenan <pmeenan@webpagetest.org>
- CC: Zhiheng Wang <zhihengw@google.com>, Jonas Sicking <jonas@sicking.cc>, Sigbjørn Vik <sigbjorn@opera.com>, public-web-perf <public-web-perf@w3.org>
We are operating on an engineering timeline in IE where we have limited time to make changes in the product, where we can ship Navigation Timing with the vendor prefixed dropped in IE9. As we are entering last call we have been operating with the assumption that the top level namespace be performance. Collectively as a working group we've been operating with the use of the top level performance namespace. Both the IE and Webkit implementation has been progressing as such. In the initial investigation across thousands of top websites, we found that the performance namespace showed up at an acceptable low risk, at 0.0093% or ~1 in 10,700 sites which is mitigated when the interface is made replaceable. Given the quantified low risks of performance, using alternate names will have similar risks. Anderson -----Original Message----- From: Tony Gentilcore Sent: Friday, January 07, 2011 9:13 AM To: Patrick Meenan Cc: Zhiheng Wang; Jonas Sicking; Anderson Quach; Sigbjørn Vik; public-web-perf Subject: Re: About window.performance namespace Now that the spec is entering last call, we've provisionally removed the prefix in WebKit (now window.performance). http://trac.webkit.org/changeset/75200 Our internal testing of ~750k URLs didn't turn up any conflicts as long as the object is replaceable (~60 uses of "var performance" or "window.performance" stomped on the built-in). Of course this is a small sample, but we take it to mean the chance of collision is acceptably low when weighed against the desire for a terse, descriptive name. If we get any bugs during the Chrome dev or beta cycles, we may be forced to choose a longer name. -Tony On Fri, Jan 7, 2011 at 3:37 AM, Patrick Meenan <pmeenan@webpagetest.org> wrote: > Maybe now would be a good time to establish a sort of reserved naming > convention for standard DOM interfaces - something like w3cPerformance? > Doesn't really roll off the tongue but it's less likely to collide and > pretty clear that it's the standardized interface. > > -Pat > > On 1/7/2011 3:13 AM, Zhiheng Wang wrote: > > On Wed, Jan 5, 2011 at 12:50 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> 2011/1/5 Anderson Quach <aquach@microsoft.com>: >> > Hi Jonas, >> > >> > You've pointed out a valid theoretical coding pattern that would >> > potentially have compatibility issues. Through the research tools that we >> > have collectively in this working group, we found that all of the patterns >> > involving the performance namespace used the initial declaration: var >> > performance. >> > >> > Using different namespaces like "pagePerformance" or >> > "performanceMetrics" does not eliminate the problem altogether. We have >> > decided to continue to use the performance namespace as it is suitable and >> > intuitive for developers when this working group adds additional attributes >> > / metrics. >> >> This doesn't make sense. Why is the litmus test "eliminate the problem >> altogether"? If something significantly reduces the problem then >> surely it's an improvement worth considering, no? >> >> You still haven't answered the question from my previous email: >> >> Is there a reason the property couldn't be named something with a >> smaller risk of collisions, such as "pagePerformance" or >> "performanceMetrics". > > This sounds like a plan to me as well... > cheers, > Zhiheng > >> >> / Jonas > >
Received on Friday, 7 January 2011 18:34:23 UTC