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

When looking for a perfect annotation for the querySelector[All] API, I think there is some sense checking existing getElementsByTagName implementations. Interesting enough:

1) Calling getElementsByTagName in SF/FF/IE with null/undefined argument values is valid and will not throw any error, presumable they call ECMA-262 ToString on the argument value.

2) Calling getElementsByTagName in SF/FF/IE with ""/"null null" argument values is valid and will not throw any error, although it should throw "INVALID_CHARACTER_ERR" since neither of the values is a valid name for an element.

I think the implementation of the querySelector[All] method should simply convert argument passed in to string, thus also allowing passing Objects with toString member implemented (this is, I guess, what exisiting implementations of XMLHttpRequest.open method do with arguments too) 

Sergey Ilinsky/


Boris Zbarsky <bzbarsky@MIT.EDU> wrote: 
I guess it might be nice if the IDL indicated which one of three cases:

1)  null means the same as "" in this case
2)  null means the same as "null" in this case
3)  null means something different from either of those two cases in this case

holds.

Then the binding layer could, for Webkit and Gecko, map cases 1 and 3 to these 
special string objects with the null bit set, and case 3 could be handled by 
hand-written code.  Case 2 would map null to the string object holding "null". 
Or something.

The Java binding layer could make null to a String holding "" in case 1, to a 
String holding "null" in case 2, and to a null String reference in case 3.  The 
you could remove your checks for an empty string in createElementNS(), etc if 
you wanted.  Again, or something.

-Boris





       
---------------------------------
Sent from Yahoo! Mail.
A Smarter Email.