Re: [XHR2] undefined as user/password arguments

On Wed, 11 Apr 2012 18:43:20 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/11/12 12:26 PM, Boris Zbarsky wrote:
>> That's not correct. For nullable types, ES undefined is converted to IDL
>> null per step 3 of
>> <http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type>. There's some
>> extra complexity there around DOMString in step 1, but it only applies
>> when [TreatUndefinedAs] is used, which it's not in this case.
>
> Though the current prose talks about "if the arguent was not omitted",  
> so treats null and undefined the same: as the argument being specified.  
>   That seems buggy for the exact reasons Jonas lists.
>
> What would make sense here is to either use [TreatUndefinedAs=Missing]  
> (and condition the "no user or password" behavior off the IDL value  
> being unspecified) or to give these things a default null value and  
> condition the "no user or password" behavior off the IDL value being  
> null.
>
> The question that should decide us between those two options is whether  
> passing null should be treated like something is set or not here.

The user/password area is a bit of a mess because of  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 and to a lesser  
extent https://www.w3.org/Bugs/Public/show_bug.cgi?id=15418 If someone  
could explain what we should do here that would be nice.


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

Received on Thursday, 12 April 2012 07:12:30 UTC