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

Lachlan Hunt wrote:
> 
> 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.

I don't actually think there is a lot to do spec-wise here. IMHO all 
that is needed is to say something like:

"An implementation encouraged to deal with hostile NSResolvers and are 
allowed to throw an exception if such resolvers are detected".

Bonus points for listing a few possible ways for hostile resolvers to 
behave, including, but not limited to:

* Taking a very long time to finish.
* Causing infinite recursion by calling .querySelector again.
* Destroying the browser context by navigating away from the current
   page.
* Mutating the DOM and/or browser context in such a way that the current
   context no longer have access to parts of the DOM that .querySelector
   was called on.

All of this is stuff that most implementations already have to deal 
with. For example if implementations implement the DOM Events 
specification which has similar callbacks.

>> 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.

Sounds good to me.

/ Jonas

Received on Monday, 12 May 2008 07:45:40 UTC