- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 12 Mar 2012 11:27:19 +1100
- To: Anne van Kesteren <annevk@opera.com>
- CC: Marcos Caceres <w3c@marcosc.com>, public-script-coord@w3.org, Boris Zbarsky <bzbarsky@mit.edu>
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