window.performance.createObserver feedback

[igrigorik]

#29 landed window.performance.createPerformanceObserver, but we have a few -1's on the new API:

PerformanceObserver should lookup the |performance| object in the context on which it's defined. That's how new Text() gets an ownerDocument, how new EventSource() finds an origin, how new Notification() works, how new Worker() gets an origin... most of the web platform is based around the idea of looking up objects in the current context -- #29 (comment).

Strong -1 for changing from new PerformanceObserver to window.performance.createObserver -- #29 (comment)

---

To lookup the performance object we can reference the "entry settings object" (EventSource example).

Any other implementation or other concerns with this API? Should we go back to new PerformanceObserver?

/cc @bzbarsky @esprehn @domenic

[bzbarsky]

Using the entry settings object would be really weird. That's not what new Text does, for sure. It can sometimes make sense for base URIs, less often for origins, never for anything else.

If you want to do what new Text does, I suspect that's using the global of the Realm of the Text function. At least in browsers. The spec for new Text doesn't really define the behavior because it talks about "the global object", which is not a defined concept in general. /cc @annevk

I still think the implicit magic is bad, but could live with it as long as it's defined properly.

[annevk]

We really need better hooks from HTML and IDL. Including some guidelines. Or a pattern that people can copy.

[bzbarsky]

Yes, we do.

[igrigorik]

@annevk @bzbarsky I'd appreciate any suggestions for how to spec this. Do we have any existing open issues to define such hooks?

[annevk]

I filed bugs against IDL and also HTML, but W3C Bugzilla is down at the moment.

[igrigorik]

Great, thanks! It'll be great to have URLs to those.

In the meantime, since folks are already implementing this interface, should we revert back to new PerformanceObserver and add a note to clarify the spec language once above bugs are resolved?

[annevk]

Why are we doing this API when we'll get FetchObserver?

[igrigorik]

Because Performance APIs are not restricted to fetch events - e.g. Frame Timing, Memory (assuming we take that on), and so on.

[igrigorik]

In the meantime, since folks are already implementing this interface, should we revert back to new PerformanceObserver and add a note to clarify the spec language once above bugs are resolved?

@mpb would you be up to create a pull to revert the constructor interface? I'm not hearing any loud objections.. think we should be ok to proceed :)

[igrigorik]

resolved via #43.