Namespace Matching in Selectors API (was: Comments on Selectors API)

Hi, SVG WG-

I just wanted to note here that the CSS WG has decided not to comment on
the Selectors API spec. [1]  They did briefly discuss the removal of
namespace matching [2], and implementor feedback was that NS support is
complex and not yet supported, so the spec should move ahead without it.
 The relevant discussion is excerpted below:

   glazou: Selectors API Last Call WD. Namespace matching was removed.
           does the WG have comments ?
   dbaron: 2/3 of the spec's complexity for implementors and the spec was
           namespaces even though most authors care less about it
   bert: is the next version going to support namespaces ?
   <glazou> http://www.w3.org/TR/selectors-api/
   <glazou> http://www.w3.org/TR/selectors-api/#resolving
   dbaron: I thought there was a plan for eventual support. BorisZ did
           have an implementation until this was dropped from the spec
   glazou: nothing in the document indicating this is to be resolved in
           a future version of the document
   glazou: dbaron, are you saying this is not worth the implementation
cost ?
   dbaron: it is worth considering for the next version. for now, this is
           the right thing to do
   <dbaron> I think what's in this draft is something that can go to REC
            quickly; if it had namespaces it wouldn't be able to.
   glazou: will communicate our WG has no further comments on Selectors
           API Last Call


I have two comments on this assessment, which we should consider
bringing up to the WebApps and CSS WGs:

1) Regarding lack of demand for the feature, I think that is more a
function of what content has been allowed in browsers up to this
point... with wider support of SVG in X/HTML, I expect that more people
are going to want to use namespaces for selectors, to do things like
differentiate between 'a' elements in SVG and HTML, or find all the SVG
(or HTML) elements.

2) If this version of the spec doesn't include NS support, it should be
supported in a second version/level, and this spec should explicitly
mention that so implementors set up their architecture accordingly.

It's worth noting that if authors need to differentiate on NS, there are
hacks to do it... for example, you could get all the 'a' elements and
then filter them on namespaceURI as a secondary step, but I won't claim
all things will be possible or easy to accomplish this way.

[1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0326.html
[2] http://lists.w3.org/Archives/Public/www-style/2008Nov/0538.html


Erik Dahlström wrote (on 11/25/08 6:45 AM):
> 
>> If the group of selectors include namespace prefixes that need to be  
>> resolved, the implementation must raise a NAMESPACE_ERR exception  
>> ([DOM-LEVEL-3-CORE], section 1.4).
> 
> Since NSResolver was taken out, please consider adding hardcoded namespace  
> prefixes for svg and xhtml similar to how the empty and any namespaces are  
> handled by this draft.
> 
> Or alternatively forward the reader to DOM 3 XPath for the cases where the
> Selectors API falls short. Even if hardcoded namespace prefixes are added
> it'd still be a good idea to link to DOM 3 XPath, since it looks like 
> Selectors API is unable to deal with arbitrary xml markup.
> 
> == 6.1 Resolving Namespaces
> 
>> A namespace prefix needs to be resolved if the namespace component is  
>> neither empty (e.g. |div), representing the null namespace, or an  
>> asterisk (e.g. *|div), representing any namespace. Since the asterisk or  
>> empty namespace prefix do not need to be resolved, implementations that  
>> support the namespace syntax in Selectors must support these. [SELECT]
> 
> Please clarify the relation between the term 'null namespace' and the term  
> 'default namespace' in CSS Namespaces[1].


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 27 November 2008 22:50:06 UTC