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/
