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

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

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sun, 11 May 2008 02:41:29 +0200
Message-ID: <482640B9.1030008@lachy.id.au>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapi <public-webapi@w3.org>

Jonas Sicking wrote:
> What are the remaining issues that are still holding us back? It seems 
> to me like if we know we're going to add this in a version 2, but we 
> already have a done specification for it, why not include it?

In relation to the NSResolver, the major issue is that I need to define 
how to handle hostile NSResolvers and deal with unexpected DOM 
modifications.

> It seems to me that implementations aren't going to be affected one way 
> or the other on this. If we do include it in the spec anyone can still 
> implement everything but namespaced selectors. I think implementors are 
> competent enough to prioritize appropriately without us holding their 
> hand. Especially if their CSS engine does not yet support namespaced 
> selectors.
> ...
> 
> I guess except that they couldn't do silly PR claims like "full 
> Selectors API v1 support"). If we wanted to satisfy such desires we 
> could say that it's ok to claim full support even without NSResolver if 
> your CSS engine does not support namespaced selectors.

I decided to retain the NSResolver in the spec for now.  However, I have 
made support for it optional and defined that if it isn't supported, a 
NOT_SUPPORTED_ERR exception must be raised if an NSResolver is passed.

You can review the changes in the latest editor's draft.

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

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Sunday, 11 May 2008 00:42:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 11 May 2008 00:42:10 GMT