This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15358 - Use the new callback syntax for Function and event handler attributes.
Summary: Use the new callback syntax for Function and event handler attributes.
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
: 15694 16320 17556 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-29 13:06 UTC by contributor
Modified: 2012-06-27 07:05 UTC (History)
9 users (show)

See Also:


Attachments

Description contributor 2011-12-29 13:06:48 UTC
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
Comment 1 Anne 2011-12-29 13:11:21 UTC
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).
Comment 2 Ian 'Hixie' Hickson 2012-02-01 00:58:54 UTC
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?
Comment 3 Cameron McCormack 2012-02-01 01:02:33 UTC
(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.
Comment 4 Anne 2012-03-12 13:24:15 UTC
*** Bug 15694 has been marked as a duplicate of this bug. ***
Comment 5 Anne 2012-03-12 13:27:13 UTC
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?".
Comment 6 Anne 2012-03-12 13:31:10 UTC
*** Bug 16320 has been marked as a duplicate of this bug. ***
Comment 7 Anne 2012-06-20 09:23:19 UTC
*** Bug 17556 has been marked as a duplicate of this bug. ***
Comment 8 Ian 'Hixie' Hickson 2012-06-22 18:14:17 UTC
Would the difference between onclick and onerror be detectable in any way?
Comment 9 Anne 2012-06-24 06:22:47 UTC
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.
Comment 10 Cameron McCormack 2012-06-24 06:28:00 UTC
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;
  };
Comment 11 Anne 2012-06-27 07:05:24 UTC
Seems this was fixed in http://html5.org/r/7146