This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The definition table of arguments of addEventListener and removeEventListenr defines the EventListener as nullable ("✔"). However, the explanation documents: The listener parameter MUST be an object that implements the EventListener interface or a function. Additionally, I have no idea the purpose of the argument nullable. So, I think that they should be "✘".
No, that would imply throwing an exception when null is passed. No browser does that.
https://github.com/w3c/web-platform-tests/pull/322
So, did you mean that it should be nullable but implementations must throw an error if null is passed?
> No, that would imply throwing an exception when null is passed. > No browser does that.
Updated text in the ED to explicitly say: "If non-null, the listener parameter MUST ..." But I don't see the point of allowing this parameter to be non-null. Adding or removing a null eventlistener seems useless.
> But I don't see the point of allowing this parameter to be non-null. The point would be if there is code on the web that does that and doesn't expect an exception. Given that no UA throws on null here, I don't think the spec should require the throwing behavior, unless you have some sort of indication that it is in fact web-compatible. Which I doubt it is, frankly.
Another way to put it: Which browsers would be willing to go first with such a change? I agree that the risk/reward ratio of changing existing implementations seem too low here.