Re: ACTION-87: Selectors API

On Sat, 25 Mar 2006, Anne van Kesteren wrote:
>
> Another draft: 
> <http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/draft/selectors-api.htm?content-type=text/html;%20charset=utf-8&rev=1.16>

I just noticed that the current text means that this is non-conformant if 
userInputIsOneThing is true:

   var s;
   if (userInputIsOneThing) {
     s = 'some random selector';
   } else {
     s = 'some|random selector';
   }
   var node = document.match(s, function(prefix) {
      if (prefix == 'some')
         return 'http://example.com';
      else
         return null;
   });

...which seems bad ("If they don't use namespace prefixes within selectors 
authors must set nsresolver to null").

Nit-picking -- the paragraph that talks about authoring requirements says 
that "when authors use namespace prefixes within selectors they must 
create an object implementing the XPathNSResolver interface" but doesn't 
require that that object be used in any way (e.g. as an argument to the 
function). It would be better to require that they pass such an argument.

Also, "In the case of ECMAScript" is probably not what is meant (what is 
"the case" of ECMAScript?).


I'm not sure about this:

   If the nsresolver argument is not of the right type UAs must raise a 
   TYPE_MISMATCH_ERR exception.

...since I would expect the behaviour to depend on the language binding. 
(In fact, in most typed languages this would be a compile-time error 
anyway, and in most non-compiled languages there are language-specific 
rules for handling attempts to invoke methods on non-objects.) In general 
I would say this applies to any DOM method, and so this draft should not 
be defining it. Based on the way it is used in DOM3 Core, I would presume 
that TYPE_MISMATCH_ERR was specifically for arguments of type "any" 
(DOMUserData). Otherwise, e.g. appendChild() would need to be defined to 
throw it when passed a non-Node.


One final note -- I saw you added a Security section. Don't say that there 
is only one problem. When you discover, in 9 years, that there is a second 
security problem with this interface, you'll look silly if you claimed 
there was only one. :-)

It's best to just say "History theft is one potential security problem".


Anyway, these are all nit-picking details, which are generally up to the 
editor to worry about, so I'll stop now. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 March 2006 23:13:41 UTC