W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: [TreatNonCallableAsNull] alternative?

From: Marcos Caceres <w3c@marcosc.com>
Date: Wed, 7 Mar 2012 11:24:31 +0000
To: Cameron McCormack <cam@mcc.id.au>
Cc: Anne van Kesteren <annevk@opera.com>, public-script-coord@w3.org, Boris Zbarsky <bzbarsky@mit.edu>
Message-ID: <E5A3B4434275479A82689B7F412D199E@marcosc.com>



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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC