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

Hi Rob,

Sorry for a late reply. First, I completely agree that what's currently in the spec is just broken. The second paragraph is the intended spec'd behavior--the others need to be removed. 

The extreme majority of event handling code on the web uses plain functions as their listeners. Early in IE9 development, we initially prototyped an implementation which supported calling handleEvent() off of function objects. However, the performance impact (as Jonas referred to) was considerable. The issue stems from the fact Jonas points out that if you take the spec'd behavior then you can determine exactly which function is the callback at *registration* time. Alternatively, if you enable calling any type of object with a handleEvent() property then you must make the determination at dispatch time (because a handleEvent function could be added at any time dynamically). For high frequency events (resize, scroll, mouse events, mutation events, etc)--especially synchronous events-- this can have considerable impact. We made the determination that we shouldn't sacrifice performance in order to enable a scenario that is extremely infrequent on the web.

Most of the scenarios where using handleEvent() is useful involve putting handleEvent on an object other than a function object (elements, generic Objects, etc.). 

Furthermore, for the vast majority of implementations, the spec'd behavior (less the errors admitted above) is interoperable. 

Finally, I think Jonas makes a good point:
> 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?
Because using functions as listeners is the primary use case on the web, I believe this is the more common thought pattern of web developers. 

I can update the spec to be clearer about this behavior. But unless there's consensus and commitment to implement from other implementers, I don't think we can change the spec to contradict what is widely interoperable. 

Regards,

Jacob

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Thursday, June 23, 2011 7:27 PM
To: Rob Brackett
Cc: Cameron McCormack; Olli@pettay.fi; www-dom@w3.org; Jacob Rossi
Subject: Re: Functions that Implement the EventListener Interface (DOM Level 3 Events)

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?

/ Jonas

Received on Friday, 24 June 2011 17:28:05 UTC