W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 12 May 2008 07:22:51 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, public-webapi <public-webapi@w3.org>
Message-Id: <7D2AB0B5-E65E-4C66-982D-A82F89682AED@apple.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>


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
Received on Monday, 12 May 2008 14:23:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 12 May 2008 14:23:34 GMT