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

On Jun 23, 2011, at 7:27 PM, Jonas Sicking wrote:

> On Thu, Jun 23, 2011 at 5:17 PM, Rob Brackett <rbrackett@apple.com> wrote:
>> 
>> 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.
> 
> Couldn't you like-wise say that it's equally predictable to have *any*
> function object always call that function to handle the event,
> independent on what properties you happened to have set on it?

You could definitely make that argument, though I'd tend to disagree. First, I didn't write the code that lead to my discovering this behavior—it was written (and reviewed!) by a team of other people. It may have been WebKit centric, but when I asked, nobody on that team knew that it wouldn't work in other browsers. It seemed common sense to them—and me, when I first saw it—that it ought to work. So clearly it's unexpected for some.

Moreover, if you're told that an event listener doesn't have to be a function—that any object can conform to the EventListener protocol by providing a "handleEvent" function property—I think it would be odd to expect that function objects are special and don't conform to the same rules as other objects. This is especially important in ECMAScript since not all function objects are meant to actually be called as functions. While constructors are technically functions, they are usually not designed to be called directly and their authors often do not think of them in quite the same way they'd think of a function they would call. I believe that dual nature of the function is actually a big part of what led to the "bug" in the code I was working on.

-Rob