Re: [TreatNonCallableAsNull] alternative?

On Tuesday, 6 March 2012 at 23:50, Cameron McCormack wrote:

> Cameron McCormack:
> > > Regardless, I don't think we want to allow [TreatNonCallableAsNull]
> > > behaviour elsewhere. It's not consistent with how type conversion is
> > > done elsewhere.
> >  
>  
>  
>  
> Anne van Kesteren:
> > Okay, so you
> >  
> > 1. Only want to use [TreatNonCallableAsNull] for event handler attributes
>  
> Yes.
>  
> > 2. Favor consistency of type conversion over event handler attribute
> > consistency
>  
>  
>  
> When it comes to using [TreatNonCallableAsNull] for things other than  
> event handler attributes, yes.
>  
> > I and some others argue for
> >  
> > A. Only want to use [TreatNonCallableAsNull] for event handler attributes
> > B. Favor consistency of event handler attributes
>  
>  
>  
> Consistency among event handler attributes? That's my preference too.  
> But not Boris'.
>  
> Anyway, the strongest objection I have in this issue is against the use  
> of [TreatNonCallableAsNull] for things other than event handler  
> attributes. My opinion on whether [TreatNonCallableAsNull] should be  
> used only for specific event handler attributes or for all of them is a  
> weak one.
>  
> > 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.
>  
>  
>  
> [Callback=FunctionOnly] is gone from the spec, so what you currently do  
> have to write is:
>  
> callback Function = any (any... arguments);
> typedef [TreatNonCallableAsNull] Function? eventhandler;
>  
> in one place, say DOM Core, and then all definitions of event handler  
> attributes can become
>  
> attribute eventhandler onblah;
>  
> I am sympathetic to having
>  
> callback Function = any (any... arguments);
>  
> built-in, in fact I would be happy to include that to the Common  
> Definitions section at the bottom of the spec, if you like.
>  
> > 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.
>  
>  
>  
> I don't see what's so bad about the one-time typedef. Typedefs exist to  
> avoid repetition like that!
>  
> Defining "eventhandler" as a built-in type in the IDL just seems like an  
> abstraction violation to me.

FWIW, I'm swinging towards agreeing with Cam here… maybe DOM4 is actually the right place to define this in the manner that he states above. DOM4 does govern event handlers after all.    

--  
Marcos Caceres

http://datadriven.com.au

Received on Wednesday, 7 March 2012 11:25:00 UTC