Re: [selectors-api] Investigating NSResolver Alternatives

Boris Zbarsky wrote:
> 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.

Yeah, I realise that.  Unfortunately, I was really busy with other 
commitments recently.

>> * 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.

Yeah, previous feedback saying something like that is why I decided to 
keep something in the spec for it.

>> * 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?

Possibly.  The algorithm says:
if ( Element's namespace != null and Element's prefix == prefix ) {
    ...
}

Since "" == null, I guess technically that means either should be 
supported.  But the definition of the prefix parameter states

   "If this parameter is null, the method will return the default
    namespace URI if any."

So the spec is really unclear about the issue.  I suppose, if we go back 
to the NSResolver function, I could make it pass "" instead of null 
anyway, and then get the DOM Core spec fixed.

http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html#lookupNamespaceURIAlgo
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-lookupNamespaceURI

>>  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.

OK.  The reason undefined was included was so that JS authors could, for 
the default namespace, not return a value which is equivalent to 
returning undefined. e.g.

function resolver(prefix) {
   if (prefix == "svg") return "http://www.w3.org/2000/svg";
}

And also so that if authors used a hash with a simple return like this:

function resolver(prefix) {
   var ns = {
     "xh"  :"http://www.w3.org/1999/xhtml",
     "svg" :"http://www.w3.org/2000/svg",
   };
   return ns[prefix.toLowerCase()];
}

and then if an undefined prefix was used, e.g.

resolver("math");

which would then return ns["math"] as undefined.  Logically that should 
throw a NAMESPACE_ERR, instead of using "undefined" as the namespace.

>> * 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.

OK, in that case, it's fine.  But it was an issue raised by Jonas:

   "Destroying the browser context by navigating away from the current
    page."

http://lists.w3.org/Archives/Public/public-webapi/2008May/0128.html

>> 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.

Is there a reason you made it resolve twice, instead of just remembering 
the value and reusing it?

> 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.

I'm not sure what you mean.

>> * 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.

Yeah, true.

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

OK.  To be honest, this was one of my other preferred options anyway.

>> 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?

Just that I personally dislike typing JSON syntax. :-)

>> 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.

Again, personal preference.

> 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.

That's unfortunate.

>> con: Browsers need to fix their buggy case folding implementations
> 
> Honestly, that's the smallest concern I have with implementing this.  ;)

I know, I just wanted to point it out as being an issue for changing to 
case insensitive prefixes.

>> 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?

I checked in an initial draft with the proposal.  There are still some 
references to NSResolver hanging around in the spec, but the actual 
authoring and processing requirements have been specified in section 6.

http://dev.w3.org/2006/webapi/selectors-api/#nodeselector

If this isn't going to work, I can easily revert to what it was before.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Saturday, 12 July 2008 16:46:55 UTC