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 16074 - Define |[TreatNonCallableAsNull] Function?| as a builtin
Summary: Define |[TreatNonCallableAsNull] Function?| as a builtin
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-02-22 11:41 UTC by Ms2ger
Modified: 2012-03-28 00:15 UTC (History)
7 users (show)

See Also:


Description Ms2ger 2012-02-22 11:41:39 UTC
Currently, WebIDL define the [TreatNonCallableAsNull] extended attribute and callbacks, both of should only be used for event handlers. It would be better to just define, say, DOMEventHandler and remove the generalized stuff.
Comment 1 Ms2ger 2012-02-22 11:45:31 UTC
Additional data point: Mozilla's new DOM bindings (WIP) only support this case for callbacks at this point: <>
Comment 2 Anne 2012-02-22 11:50:52 UTC
Callbacks are also useful alone. But yes, I suggested a native type for event handlers in the past:
Comment 3 Cameron McCormack 2012-03-05 00:10:47 UTC
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.
Comment 4 Anne 2012-03-05 07:25:58 UTC
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?
Comment 5 Ms2ger 2012-03-05 17:30:46 UTC
Indeed. Furthermore, we want it for *all* onfoo attributes, not just the old ones.

Please register my formal objection to this decision.
Comment 6 Marcos Caceres 2012-03-05 17:34:34 UTC
I would also like to register a formal objection to this decision. Rationale is the same as that given by Anne and Ms2ger
Comment 7 Travis Leithead [MSFT] 2012-03-05 17:50:02 UTC
(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.
Comment 8 Ms2ger 2012-03-05 18:01:59 UTC
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.
Comment 9 Marcos Caceres 2012-03-05 18:03:30 UTC
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".
Comment 10 Cameron McCormack 2012-03-05 23:50:47 UTC
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.
Comment 11 Cameron McCormack 2012-03-06 04:38:25 UTC
(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. :)

Anyway, please note that Formal Objections are made in response to Working Group decisions, 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.
Comment 12 Anne 2012-03-06 08:41:06 UTC
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.
Comment 13 Boris Zbarsky 2012-03-06 13:45:38 UTC
> Unless Boris is reviewing it, I guess. :)

This is why we have two reviews for API changes?  ;)
Comment 14 Marcos Caceres 2012-03-28 00:15:27 UTC
I support the second suggesting made at the bottom of this email:

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