Re: [TreatNonCallableAsNull] alternative?

Anne van Kesteren:
> The point I am making is that by having [TreatNonCallableAsNull] at all
> you introduce the possibility of it being used for other things. If
> instead you only defined the only thing for which it will ever be used,
> namely "[TreatNonCallableAsNull] attribute Function?" -> "eventhandler"
> you avoid that possibility. Given that you do not actually define event
> handler attributes I don't think it's a layering violation. It's just a
> special type of callback that happens to be extremely common in the
> platform of which the semantics of the members that use it are defined
> in HTML (or by reference to the event handler attribute concept in HTML).

I agree event handler attributes are extremely common.  So they need to 
be defined in one place and then referenced everywhere else.  I really 
am not sure that would prevent the accidental proliferation of the 
[TreatNonCallableAsNull] behaviour any more than by defining 
"eventhandler" as a built-in type.  We're going to need to have similar 
warnings against using "eventhandler" in places where we don't want this 
"values converted to null" behaviour to be, if we are worried about this.

> Web IDL defines "eventhandler" as special callback. HTML defines "event
> handler attribute" (which has some other legacy baggage besides IDL
> syntax) so we can introduce "on..." members throughout the platform.

Actually, why is it that HTML declares Function with (any...) arguments 
rather than (Event event)?  onerror would need to take a different 
callback type of course.  I think this would be more informative to 
people reading the IDL.

Anyway, if we did have it take (Event event) then we'd have a dependency 
on DOM Core.  We would need to leave it as (any...) to avoid that.

>> I don't see what's so bad about the one-time typedef. Typedefs exist
>> to avoid repetition like that!
>
> The point is more that it would be the only place where
> [TreatNonCallableAsNull] would ever be used. That seems silly.

There are various other extended attributes used in only one or two 
places.  I like to think of extended attributes as being uncommon tweaks 
to the default way the bindings are handled.

(Constructors feel out of place to me; maybe they should have got first 
class syntax.)


My suggested course of action is still the following:

* Keep [TreatNonCallableAsNull] in Web IDL.

* Add the following definition to DOM Core or HTML, whichever is more 
appropriate:

     callback EventHandlerCallback = any (Event event);
     typedef [TreatNonCallableAsNull] EventHandlerCallback? EventHandler;

* Add the following definition to HTML:

     callback ErrorEventHandlerCallback = any (Event event, DOMString 
source, unsigned long lineno, unsigned long column);
     typedef [TreatNonCallableAsNull] ErrorEventHandlerCallback? 
ErrorEventHandler;

* Then event handler attributes get defined as:

     attribute EventHandler onclick;
     attribute EventHandler onmousemove;
     attribute ErrorEventHandler onerror;


Alternatively, we could allow [TreatNonCallableAsNull] to be specified 
directly on the callback, skip the typedef altogether, and use the "?" 
in the IDL attribute declarations -- that's probably clearer for 
indicating that null is allowed, tbh:

* Keep [TreatNonCallableAsNull] in Web IDL but allow it on callback.

* Add the following definition to DOM Core or HTML, whichever is more 
appropriate:

   [TreatNonCallableAsNull]
   callback EventHandler = any (Event event);

* Add the following definition to HTML:

   [TreatNonCallableAsNull]
   callback ErrorEventHandler = any (Event event, DOMString source, 
unsigned long lineno, unsigned long column);

* Event handler attributes get defined as:

     attribute EventHandler? onclick;
     attribute EventHandler? onmousemove;
     attribute ErrorEventHandler? onerror;


Actually I'm liking this second option better.

Received on Monday, 12 March 2012 00:28:01 UTC