- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Sun, 12 Aug 2012 06:36:08 +0000
- To: Brendan Eich <brendan@mozilla.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
-----Original Message----- From: es-discuss-bounces@mozilla.org [mailto:es-discuss-bounces@mozilla.org] On Behalf Of Brendan Eich Sent: Saturday, August 11, 2012 22:57 > As noted, they started out that way 17 years ago. I think WebIDL and interface-based method definition made onload, e.g., predefined on window objects, or more recently on Window.prototype. Was this useful? > Was it intended specifically (for window, not just intended generally due to WebIDL's uniform rules for binding its definitions in JS)? As a developer, the fact that the properties already exist and are set to null is useful for feature-detection. E.g. any of the following will test for the presence of cross-document messaging: "onmessage" in window window.onmessage !== undefined window.onmessage === null // assuming no badly-behaved third-party scripts It is also useful strictly from a development POV, because typing `window.on` in the Firefox or Chrome console gives a list of supported events. FWIW, my mental model is probably closest to these being non-magical own data properties, pre-initialized to null, that the browser will read from and use when it fires the corresponding event. They don't make much sense as accessors to me.
Received on Sunday, 12 August 2012 06:36:42 UTC