15358 2011-12-29 13:06:48 +0000 Use the new callback syntax for Function and event handler attributes. 2012-06-27 07:05:24 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#function P3 normal --- 1 contributor ian annevk cam dom ian mike mounir public-html-admin public-html-wg-issue-tracking w3c public-html-bugzilla oldest_to_newest 62126 0 contributor 2011-12-29 13:06:48 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html Multipage: http://www.whatwg.org/C#function Complete: http://www.whatwg.org/c#function Comment: Use the new callback syntax for Function and event handler attributes. Posted from: 83.85.115.123 by annevk@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.2; U; en) Presto/2.10.229 Version/11.60 62127 1 annevk 2011-12-29 13:11:21 +0000 In particular it should be something like this: callback EventHandlerListener = void (Event evt); typedef [TreatNonCallableAsNull] EventHandlerListener? EventHandler; Event handler IDL attributes can then be defined as attribute EventHandler onclick; The event handler attributes that take a different argument (onerror, others?) it probably makes sense to define a distinct callback so it is clear they are special from the IDL as well. Cameron suggested EventListener elsewhere but that would be incompatible with the DOM (where it is a callback interface). 63504 2 ian 2012-02-01 00:58:54 +0000 Wouldn't this mean you can't assign a zero-argument method as a callback? Surely the return value should be boolean, not void. What about things like onbeforeunload, where the value can be as string, too? 63507 3 cam 2012-02-01 01:02:33 +0000 (In reply to comment #2) > Wouldn't this mean you can't assign a zero-argument method as a callback? No, zero-argument Functions can be passed in just like they could before with [Callback] interface. > Surely the return value should be boolean, not void. What about things like > onbeforeunload, where the value can be as string, too? Either broaden the return type, or use separate callback definitions for the event handler IDL attributes that have different return types. 65346 4 annevk 2012-03-12 13:24:15 +0000 *** Bug 15694 has been marked as a duplicate of this bug. *** 65347 5 annevk 2012-03-12 13:27:13 +0000 The new syntax for this is: [TreatNonCallableAsNull] callback EventHandler = any (Event event); For window.onerror you will need something special, e.g. [TreatNonCallableAsNull] callback ErrorEventHandler = any (any... args); To reference it you would use "EventHandler?". 65349 6 annevk 2012-03-12 13:31:10 +0000 *** Bug 16320 has been marked as a duplicate of this bug. *** 69284 7 annevk 2012-06-20 09:23:19 +0000 *** Bug 17556 has been marked as a duplicate of this bug. *** 69347 8 ian 2012-06-22 18:14:17 +0000 Would the difference between onclick and onerror be detectable in any way? 69357 9 annevk 2012-06-24 06:22:47 +0000 As far as I can tell from reading IDL they would be treated identically in JavaScript so I suppose you might as well merge them and add a comment that in the common case an Event object is passed or some such. 69358 10 cam 2012-06-24 06:28:00 +0000 I think there is some value in keeping the types of onerror and the others different, just to help people reading the IDL. For the same reason you use the most restrictive type for your attributes, rather than interface HTMLElement { ... readonly attribute any classList; }; 69452 11 annevk 2012-06-27 07:05:24 +0000 Seems this was fixed in http://html5.org/r/7146