W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2011

Re: Functions that Implement the EventListener Interface (DOM Level 3 Events)

From: Rob Brackett <rbrackett@apple.com>
Date: Thu, 23 Jun 2011 17:17:00 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, "Olli@pettay.fi" <Olli@pettay.fi>, "www-dom@w3.org" <www-dom@w3.org>, Jacob Rossi <jrossi@microsoft.com>
Message-id: <D6A11A37-5F05-4408-B7D4-D5515F1A9A5F@apple.com>
To: Cameron McCormack <cam@mcc.id.au>

On Jun 23, 2011, at 4:59 PM, Cameron McCormack wrote:

> Rob Brackett:
>> It's just frustrating, as a content author, that it's a little
>> unpredictable and that it removes the easy ability to have "this"
>> point to my object instead of to the DOM node that fired the event.
> Do you mean unpredictable because of non-interoperability?  Then sure, I
> think thatís what we all want to fix. :-)

No, actually, but I do agree that interoperability is important for authors to be able to work more easily.

It seemed like a pretty natural expectation that, if the listener was an object of *any* sort and had the "handleEvent" property on it, the function that was the value of "handleEvent" should be called. It just so happened that all the preliminary work was done on various flavors of Safari, which reinforced the prediction/expectation. Browsers like Chrome, Firefox, and IE would break that prediction instead and therefore provide an "unpredictable" or "inconsistent" API, which is what I meant.

Since interoperability and predictability/consistency within the API are both important but not the same, I thought this would worth bringing up as a possible change to the spec. If WebKit+JavaScriptCore changes to match the spec, we'll have interoperability but poor predictability in the API. It would be nice to have both. That is to say that I doubt any other browser vendors would change to differ from the spec, but they might change if the spec changes.

In the end, interoperability trumps API predictability, so if there is no interest in making a change to the spec, WebKit will need to change. It seemed worthwhile to put the question out for consideration, though.

> Note this is only an issue for when you have an object that is *both* a
> Function object and has a handleEvent property.  If you want an object
> for you this, donít use a function.

Yes! That much is well understood. I hoped to illustrate with my earlier example of a constructor with "class properties" that the case of a Function object with a handleEvent property is not as rare as one might first expect.

Received on Friday, 24 June 2011 00:17:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC