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

On Jun 24, 2011, at 10:27 AM, Jacob Rossi wrote:

> 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.

Ah, this is pretty much what I had assumed was being done in IE, but I hadn't expected that it would really have a huge impact. Obviously WebKit+JavaScriptCore is currently checking for the presence of handleEvent() whenever the event listener is being called. I am now very curious to see what the performance difference looks like in JavaScriptCore for these "hot" events. 

It does seem like there might be some other ways to optimize this, though—you could potentially have a way for the engine to mark properties as dirty, for example, and still do the determination at registration time and only re-evaluate if "handleEvent" is dirty at call time. I can imagine you might have tried something like this, though. If you did, did it not work out very well?

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

Well, it certainly seemed useful on that constructor function that revealed the issue to me in the first place ;)

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

That IE, Firefox, and Chrome all behave the same is certainly a concern. I'd agree: the change I'm hoping for is certainly not worth making if the various vendors that match the current spec are not interested in changing (for performance reasons or otherwise). The only way to gauge that interest was to ask! 

I also would not have asked if *all* major implementations I knew of were interoperable. At the end of the day, whether spec changes or not, some implementations will have to change if we want interoperability. I'd just rather it not be WebKit+JavaScriptCore, since its current behavior has been pretty useful to me and others I work with :)

-Rob



> 
> 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 19:55:15 UTC