Re: About window.performance namespace

   Thanks to all for chiming in with many perspectives! Given the imminent
timing line let's make the call on this
topic and move forward: NavigationTiming will use window.performance object,
which itself is replaceable.

   Here are the points we've covered so far to reach this decision:
  - There is interest to keep the interface concise, which has its own
advantage in the long run.
  - Most of us agree that we should avoid the potential conflicts with
existing pages. Having window.performance replaceable
    address that.
  - Probably a common practice, having window.performance replaceable could
still confuse some. But so far there
    doesn't seem to be any objection to that.
  - There is some risk allowing developers to replace window.performance.
But considering most objects/functions
    are replaceable in ECMA scripts, protecting window.performance alone
could be a half-way solution to integrity
    of the collected. So best intentions are assumed.
  - Less of an argument... but this is the current implementation adopted by
IE and Chrome.

cheers,
Zhiheng

On Fri, Jan 7, 2011 at 9:11 AM, Tony Gentilcore <tonyg@google.com> wrote:

> 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
> >
> >
>