Re: [TreatNonCallableAsNull] alternative?

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

> Cameron McCormack:
> > > Which event listener attributes do we actually *need* it for currently?
> >  
>  
>  
> Marcos Caceres:
> > http://specs.wacapps.net/webview/#the-onclose-attribute
> >  
> > (yes, I know it's not part of the Web Platform… a man's gotta pay his bills somehow :( )
>  
> Sorry, I meant which event listener attributes do we need the lenient  
> behaviour for because of existing Web content that would break otherwise.

Ah sorry, misread.   
> > > 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.
> >  
> > I can see what you mean. I guess my perspective is that I got used to
> > the [TreatNonCallableAsNull] behaviour over many years... so I kinda
> > see it's behaviour as a feature, not a bug.
>  
> I find this surprising. You deliberately rely on the fact that  
> assigning say a Node or a Number or a String to window.onblah does the  
> same as assigning null to it?

I know, it's stupid. And I don't rely on it on the way you state (i.e., the examples you give are indeed ridiculous… "oh, gotta set this to null, so I better set it to a random Node!" :)). But window.onload = ""; is not the most offensive thing I've ever seen.       
> > > Regardless, I don't think we want to allow [TreatNonCallableAsNull]
> > > behaviour elsewhere. It's not consistent with how type conversion is
> > > done elsewhere.
> >  
> > I know; but these "event handler IDL attributes" are kind of a
> > special case with a long legacy
>  
>  
> When I say "I don't think we want to allow [TreatNonCallableAsNull]  
> behaviour elsewhere", I mean for things other than event handler attributes.

Oh, I agree. Don't want that either.

Received on Wednesday, 7 March 2012 11:22:22 UTC