Rather than overload the 3rd argument of addEventListener could we overload the 2nd?

[RByers]

The 2nd argument to addEventListener is an EventListener callback interface. We could possibly add additional attribute members to this interface. Eg.

callback interface EventListener {
  void handleEvent(Event event);
  readonly attribute boolean mayCancel;
};

Event registration code would then look like:

element.addEventListener(type, {handleEvent: function(e) {
    ...
  }, mayCancel: false});

This would separate capture from mayCancel but it makes some sense since mayCancel is describing a property of the EventListener. This would have the benefit of being backwards compatible (although we'd still want to encourage use of a polyfill to prevent accidentally depending on cancelable events). This would also avoid the need to change any of the language around the capture variable and what constitutes a redundant (and so ignored) event handler registration. However this seems like it might be an abuse of callback interfaces, is there precedent?

[RByers]

We couldn't do the above as it would be a breaking change due to the definition of single operation callback interfaces, plus we'd need some way to indicate the default value for myCancel. Maybe:

callback interface EventListenerWithOptions extends EventListener {
  readonly attribute boolean mayCancel;
};
partial interface EventTarget {
  void addEventListener(DOMString type, EventListenerWithOptions callback, optional boolean capture = false);
  void removeEventListener(DOMString type, EventListenerWithOptions callback, optional boolean capture = false);
};

But this still doesn't scale nicely to support other optional options. Perhaps we could use a dictionary with a handleEvent callback function member?

[AshleyScirra]

Why not go further and make all parameters passed through a dictionary?

target.addEventListener({
    type: "scroll",
    handler: function (e) { ... },
    useCapture: false,
    mayCancel: true
});

This seems tantamount to a full API redesign though, and probably would deserve a new function name too..

[annevk]

Going to close this. Callbacks should be simple functions, the interface callback thing is mostly about compatibility.

[RByers]

SGTM, thanks

[RByers]

Give the ongoing debate here let's hash this out a little further. Would it really be so bad to have this?

callback interface EventListener {
  void handleEvent(Event event);
  readonly attribute boolean capture;
  readonly attribute boolean passive;
};

I know callback interfaces have fallen out of favor, but my reading of the WebIDL spec around this suggests that there's nothing really wrong with the above pattern. Maybe it's a reasonable pragmatic trade off to resolve the dispute in #12 in a way everyone can live with? We, of course, can still aim to replace addEventListener in the future to get rid of this legacy long-term. But is there some reason why this design would be really bad? It's certainly not too ugly from the web dev standpoint. Eg:

element.addEventListener(type, {passive:true, handleEvent: function(e) {
    ...
  }});

Seems nicer to me than:

var supportsPassive = false;
document.createElement("div").addEventListener("test", function(){}, { get passive() { supportsPassive = true }});
element.addEventListener(type, function(e) {
  ...
}, supportsPassive ? { passive: true } : false); 

@annevk @domenic @smaug---- @tabatkins @paulirish @jacobrossi @esprehn @grorg @foolip @phistuck @dtapuska

[jacobrossi]

+1

handleEvent will be part of the event listener paradigm until we replace aEL (note a similar behavior exists for handleChange in MediaQueryListener). So it's seems sensible to me to resolve #12 this way until that time.

[smaug----]

So {handleEvent: function(){}} would behave as now, but there could be possibly also passive and capture boolean properties in object passed in?
Or was readonly attribute boolean cancel; on purpose? (I think you mean capture)

[RByers]

So {handleEvent: function(){}} would behave as now, but there could be possibly also passive and capture boolean properties in object passed in?

Right

Or was readonly attribute boolean cancel; on purpose? (I think you mean capture)

Ooops, thanks - fixed.

[RByers]

And to be concrete, I'm also proposing we'd change the existing boolean capture arg to optional and specify that when it's specified it takes precedence over the capture property here.

Alternately I'd be OK omitting a duplicate capture entirely if people would prefer that (though I know Tab and Anne among others would like some path for improving the syntax for capture).

[paulirish]

IMO the ergonomics of using the EventListener callback interface for these options is a huge win. It makes for far more predictable behavior for older browsers. And yeah, as the examples in Rick's comment above shows, the code is far more readable.

[smaug----]

The current boolean capture (3rd param) is already optional.

I'd prefer to not add capture to this 2nd param approach. There isn't really any need for that, and it just adds compat risk, similar to the 3rd param approach.

Without capture in 2nd param, I'm ok with this approach. Spec'ing it shouldn't be too hard.
The passive property would be read as if the passed object was a dictionary (so read only once when the addEventListener is called), but otherwise 2nd param would work as it works now.