On May 12, 2008, at 6:16 AM, Lachlan Hunt wrote:
This is possible, since the spec is already compatible with
Node.lookupNamespaceURI(). I think it would just require that a
Node be passed and ignore any other type of object. But, there are
a few problems with the approach.
If scripts were to use elements from the actual document to obtain
prefixes, it ties the script to that document and others that use
the same prefixes only. Scripts intended for reuse elsewhere would
need to construct their own node and set all necessary namespaces.
The code for creating that is, unfortunately, a little complex, and
so it is not ideal.
var nsresolver = document.createElementNS("http://www.w3.org/1999/xhtml
", "div");
nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/";, "xmlns",
"http://www.w3.org/1999/xhtml";);
nsresolver.setAttributeNS("http://www.w3.org/2000/xmlns/";,
"xmlns:svg",
"http://www.w3.org/2000/svg";);
nsresolver.setAttributeNS("http://www.w3.org/2000/, "xmlns:math",
"http://www.w3.org/1998/Math/MathML/";);
With HTML5 available (and therefore innerHTML on XML nodes), I'd do it
like this:
var doc = document.implementation.createDocument();
doc.firstChild.innerHTML=
'<nsNode xmlns="http://www.w3.org/1999/xhtml"; xmlns:svg="http://www.w3.org/2000/svg
" xmlns:math="http://www.w3.org/1998/Math/MathML/"; />';
var nsNode = doc.firstChild.firstChild;
That doesn't look so bad for authors. But see also my alternative
proposal.
The Namespace URI Lookup algorithm [1] seems to indicate that the
element needs to have an expicit xmlns attribute set in order to get
the default namespace from its value, instead of just obtaining it
from the element's actual namespace. But the problem is,
implementations don't agree with each other. They also don't agree
on what to return when the paramter is null, undefined or "".
If querySelector takes a node, it doesn't matter what the Namespace
URI Lookup algorithm says because Selectors API can iteself spec
something useful and consistent notwithstanding what
Node.lookupNamespaceURI does.
The bottom line here is that we're trying to represent what should
really be a simple dictionary with a function, and it creates all
sorts of unnecessary complexity.
Regards,
Maciej
