Re: [selectors-api] Investigating NSResolver Alternatives

Lachlan Hunt wrote:
> I realise that there is work going into 
> implementing the current NSResolver as currently specced, but no 
> implementation has shipped yet, so it's not too late

For what it's worth, it might well be too late as far as Gecko is concerned.  I 
have NSResolver implemented as currently specified (modulo the "undefined" 
thing), and we're aiming to be done with this next release in a timeframe that I 
suspect is shorter than the time it'll take to spec and implement something else.

I have to admit that it would have been nice to have _some_ communication on 
this a few weeks back when I asked what the current state of things with 
NSResolver was prior to spending time on implementing it.

> * Deferring it until v2 and having browsers ship without support for
>   NSResolver in inital implementations

I think Gecko would be strongly interested in allowing full namespace support in 
querySelector, so would like to avoid this scenario.

> * Resolving the default namespace
> 
> The DOM 3 Core Node.lookupNamespaceURI required null to be passed in 
> order to obtain the default namespace, but it would be better for both 
> authors and implementers if this were "" instead.

Didn't someone recently say that treating "" and null here as equivalent (as 
Gecko does) was correct?

>  However, Boris has reported this is an
> implementation problem because they are converted to "null" and 
> "undefined" as a result of the return value being defined as a DOMString.

I reported that this is an issue with "undefined".  |null| is converted to "" in 
Gecko (as well as Webkit, last I checked).  There was a whole thread on this 
earlier.  The key difference is that technically |null| is a valid DOMString 
value as far as the rest of the DOM is concerned (and in Java, say, is a null 
object reference), while |undefined| is in no way special as far as 
stringification goes.

> * Navigating away from the page
> 
> var iframe = getElementById("theIframe");
> function resolver() {
>   iframe.location = "...";
> }
> 
> iframe.document.querySelectorAll("p", resolver);
> 
> I'm not really sure what should or could happen there.

I don't see the problem: navigation is async, while the query is sync.

> If the browser resolves a prefix multiple times, e.g. if given the 
> selector "x|p x|span", what if it returns inconsistent results?  Opera 
> currently does this, but still uses first value returned anyway.

Gecko's current implementation would resolve twice in this case and use the two 
values.  That's not something to rely on, though.

Your list of use cases does not include "ability to resolve any namespace prefix 
in the selector to something (at least '') without knowing anything about the 
selector string".  There was one mention of this as a use case earlier, but I'm 
not sure whether it's one we care about.

> * Use the JS Object notation: {"prefix": "uri", ...} (Hash map)
> 
> pro: Easy and familiar for authors
> pro: Browsers already support it
> con: Only suitable for ECMAScript, though other language bindings could 
> use their own Map implementation

You forgot:

   con: has all the problems of the function approach, because of getters.

> * Requiring a Node with appropriate namespace declarations to be passed.
> 
> pro: Easy for implementations to obtain the namespaces
> con: More complex for authors to create a node and set all necessary 
> namespaces
> con: Using a Node from the document itself ties the script to use the 
> same prefixes as the document.

This last need not be true if one just creates the node on the fly, but I agree 
that this seems like a pain for authors.

> * Defining a new native object that can have namespace declarations
>   added to it by scripts.
> 
>   var resolver = new NamespaceResolver()
>   resolver.add("prefix", "uri");
> 
> pro: Easy for authors to use
> pro: Relatively easy for implementers to implement
> con: Requires me to specify a new interface

Honestly, that last con might only apply to the "* Easy to define in the spec" 
requirement, and I don't think it's that big a deal in terms of difficulty of 
definition.

Offhand, this sounds like the simplest approach to me if we do decide to change 
things around at this late date.

> DOMString: JSON syntax '{"prefix": "uri"}'
> con: Quite verbose for authors

It doesn't seem any more verbose than any other solution here.  Am I missing 
something?

> DOMString: the @namespace syntax defined in CSS.
> con: Slightly verbose for authors, but less verbose than JSON

This seems a good bit more verbose that JSON to me.  Again, what am I missing.

I admit this is also a tempting alterntative, though it requires more surgery 
than the other approaches here (e.g. not creating actual namespace rules in the 
parser when parsing this, etc).  It's probably a lot more of a pain to implement 
than you seem to think.

> con: Browsers need to fix their buggy case folding implementations

Honestly, that's the smallest concern I have with implementing this.  ;)

> I will draft up the replacement specification for this shortly

Can you possibly give a timeframe here?  Are we talking a day or two?  A week? 
A few weeks?

-Boris

Received on Saturday, 12 July 2008 15:30:10 UTC