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

Re: [TreatNonCallableAsNull] alternative?

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 07 Mar 2012 10:59:06 +1100
Message-ID: <4F56A4CA.2080402@mcc.id.au>
To: Marcos Caceres <w3c@marcosc.com>
CC: Anne van Kesteren <annevk@opera.com>, public-script-coord@w3.org, Boris Zbarsky <bzbarsky@mit.edu>
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.

>> 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?

>> 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.
Received on Tuesday, 6 March 2012 23:59:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC