W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: [selectors-api] Extended Attribute [NoNull] in the IDL

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 2 May 2008 20:30:45 -0700
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <C1FBCE83-87A3-491D-9533-E6282E345048@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On May 2, 2008, at 8:17 PM, Boris Zbarsky wrote:

> Cameron McCormack wrote:
>> I think of it more like that null is the actual namespace URI  
>> value, and
>> that an empty string is the non-standard way of specifying it (rather
>> than the other way around).  Which makes me think of this more as
>> something the method should handle, rather than something the  
>> bindings
>> worry about.
> But the method signature in IDL is DOMString.  So by the time it  
> sees the argument, it will be a DOMString.  The only question is  
> which DOMString.
> In Gecko, if you pass in "" it will see the string "".
> If you pass in null, it will see a string that is equal to "" but  
> has a "this is a null string" bit set.
> Conceptually, the latter is more like a |char * str = NULL| and the  
> former is more like a |char * str = "";| but both represented by a  
> String object of some sort.

This is essentially what WebKit does as well (for methods where we've  
indicated null should convert to null string). In other cases, the  
default JS rule is used, yielding "null".

> It might make sense to declare this the default conversion of null  
> to DOMString and then have NoNull mean that the  
> Object.prototype.toString conversion should be used instead.

It would be a little awkward that the DOM default is not the same as  
JS language builtins but we effectively have this problem already.

Received on Saturday, 3 May 2008 03:31:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC