- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 12 Apr 2012 09:11:57 +0200
- To: public-webapps@w3.org, "Boris Zbarsky" <bzbarsky@mit.edu>
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