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 HTML spec says that event handler idl attributes (e.g., onload) the should be set with using objects that implement the Function interface. However, DOM4 allows objects that implement EventListener to be used (e.g., addEventListener({handleEvent:...})). From a developer perspective, this is inconsistent in that there are two ways of doing conceptually the same thing. What is interesting is that Webkit-based browsers support both approaches (which is good, IMO), while IE and Moz don't. Opera is somewhere in the middle: today, it supports using EventListener interface on Nodes (e.g., element.onclick) but not on the Window object. For more details, please see: http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0073.html
There doesn't seem to be much point in using objects here given that you can put attributes on Function objects.
(In reply to comment #1) > There doesn't seem to be much point in using objects here given that you can > put attributes on Function objects. Yes, I agree. But then why do we need to define EventListener in DOM4 instead of just using Function? My concern is simply that we should use one or the other. Supporting two ways of doing the same thing has led to confusion in implementations (Opera's implementation for instance, which supports EventListener on some attributes, but not on others - though Anne claims they've now fixed this internally). Also, Chrome supports assigning either an Object or a Function. Supporting EventListener on event handler idl attributes would give us the best of both worlds (you can use a function or an object)... but that might upset non-webkit browsers. Having said that, I don't mind if we close this bug and keep the current inconsistant behaviour. I just wanted to raise it as I ran into this while I was creating some tests for a test suite.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The current inconsistent behavior seems to be the shortest path to interop.