Re: [TreatNonCallableAsNull] alternative?

On Tue, 06 Mar 2012 05:24:04 +0100, Cameron McCormack <cam@mcc.id.au>  
wrote:
> Which event listener attributes do we actually *need* it for currently?  
>   Is it a set that might creep to become bigger?  Consistency across all  
> event listener attributes seems nice to me, but I admit it is trading  
> off against hiding authoring errors.

We could still flag it in the console.


> Regardless, I don't think we want to allow [TreatNonCallableAsNull]  
> behaviour elsewhere.  It's not consistent with how type conversion is  
> done elsewhere.

Okay, so you

1. Only want to use [TreatNonCallableAsNull] for event handler attributes
2. Favor consistency of type conversion over event handler attribute  
consistency

I and some others argue for

A. Only want to use [TreatNonCallableAsNull] for event handler attributes
B. Favor consistency of event handler attributes

So it seems we both only want [TreatNonCallableAsNull] for event handler  
attributes, but the disagreement is about whether all event handler  
attributes should be the same IDL-wise. So lets focus on that (maybe issue  
a CfC?) because I think it would be really great if

[TreatNonCallableAsNull] attribute Function? oncanplaythrough;

[Callback=FunctionOnly, NoInterfaceObject]
interface Function {
   any call(any... arguments);
};

could become

eventhandler oncanplaythrough;

with "eventhandler" being a defined type in IDL reserved for members  
starting with "on" having equivalent semantics to other members starting  
with "on" throughout the platform.

On top of that you still need the boilerplate language from HTML (which  
cannot move to DOM last time I checked because some dependencies), but at  
least the IDL will look clean, [TreatNonCallableAsNull] will not  
accidentally be used elsewhere, and one-time typedef's are not needed  
either.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 6 March 2012 09:42:01 UTC