Additional data point: Mozilla's new DOM bindings (WIP) only support this case for callbacks at this point: <https://hg.mozilla.org/users/jst_mozilla.com/dom-bindings/file/7e6c70d95373/dom/bindings/Codegen.py#l640>

Callbacks are also useful alone. But yes, I suggested a native type for event handlers in the past: http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/0377.html

I don't think we need this in IDL, because I think we only want to support it for event handler attributes.  I think it would be preferable to throw if we could, but for legacy.  In the IDL in DOM Core we can easily write

  typedef [TreatNonCallableAsNull] Function? EventHandler;

for example, and then all specs that define event handler attributes just use "EventHandler" as the type.

As this is a LC comment, please let me know if you are dissatisfied with this resolution.

Since we only want it for event handler attributes, isn't that a very good reason not to introduce a generic construct such as "[TreatNonCallableAsNull]" but instead a specific construct for event handler attributes?

Indeed. Furthermore, we want it for *all* onfoo attributes, not just the old ones.

Please register my formal objection to this decision.

I would also like to register a formal objection to this decision. Rationale is the same as that given by Anne and Ms2ger

(In reply to comment #5)
> Indeed. Furthermore, we want it for *all* onfoo attributes, not just the old
> ones.
> 
> Please register my formal objection to this decision.

What is the basis for your objection? Do you think that having event handler attributes translate any non-function value into null is the right behavior? Or are you pushing for consistency with existing [legacy] behavior?

Apparently there are a large number of W3C specs out there that jumped on this syntax right away, without understanding that the syntax was intended for legacy APIs. Due to the copy/paste nature of spec authors, the current approach is likely to fail in its goal (of being for legacy event handlers only). 

Perhaps a rename of the attribute is in order (similar to legacycaller)... or we simply re-examine what we think is the acceptable behavior for *all* event handlers, and reduce the friction by removing this attribute and creating a bona-fide mechanism as has been suggested.

I'd be supportive of either of the above outcomes, but considering how the [TreatNonCallableAsNull] extended attribute is being proliferated, "Won't Fix" may not be appropriate.

It is ridiculous to make different onfoo attribute have different behaviour; I am not aware of anybody arguing against that, and I am pretty sure that would not pass review in Gecko.

My objection is that recommending avoiding the use of [TreatNonCallableAsNull] makes event handlers in new specs behave in a way that is different from other specs (e.g., HTML5's on*). This is confusing in that it means some event handlers behave one way, and other (new ones) in another way... I am not the best to judge, but I kinda like the behavior of [TreatNonCallableAsNull]. 

Having said that, I would be strongly in favor of having a general mechanism for defining "event handler IDL attributes".

Whether we want all event listener attributes to use [TreatNonCallableAsNull] or not is beside the point.  (I don't know if there is agreement either way on that -- my own opinion is that it would be better to have all event listener attributes behave consistently, even if only a select few needed the [TreatNonCallableAsNull] behaviour for current web content.  If we need to change the warning that is in the spec at the moment, that is up for discussion.)

But I don't see the need to use [TreatNonCallableAsNull] anywhere else other than event listener attributes.  For that reason, I don't think it needs to gain first class IDL syntax.  And as we've already discussed in the other bug, callbacks are not just for EventListener.

It is possible to define how event listener attributes work using the existing Web IDL functionality with the typedef in comment 3; DOM Core can define this and all specs defining event listener attributes can reference it.

*If* we wanted [TreatNonCallableAsNull] behaviour for *all* callbacks -- not just those for event listener attributes -- then we could get rid of it and build its behaviour into the "convert JS value to IDL callback value" algorithm.  But I don't think that's what we want.

(In reply to comment #8)
> It is ridiculous to make different onfoo attribute have different behaviour; I
> am not aware of anybody arguing against that, and I am pretty sure that would
> not pass review in Gecko.

Unless Boris is reviewing it, I guess. :)
http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0187.html

Anyway, please note that Formal Objections are made in response to Working Group decisions http://www.w3.org/2005/10/Process-20051014/policies.html#WGArchiveMinorityViews, which for Web IDL so far have only been made for document publication.  So I can take the Formal Objections as being to whatever upcoming document publication request we have.

So you actually want two different types of event handler attributes? Maybe we should try to have some kind of CfC about this because I'm not sure the wider WG will agree with you.

> Unless Boris is reviewing it, I guess. :)

This is why we have two reviews for API changes?  ;)

I support the second suggesting made at the bottom of this email:

http://www.w3.org/mid/4F5D42E7.4080705@mcc.id.au

I would like to withdraw my formal objection in light of Cam's proposal.