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

On May 12, 2008, at 12:44 AM, Jonas Sicking wrote:

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

Having considered it for some time, I think running arbitrary code to  
resolve namespace prefixes is a bad approach.

A function is not a particularly convenient way to specify a namespace  
mapping, and it creates these error handling issues as well as causing  
problems with case (in)sensitivity. Even though NSResolver is what  
XPath uses, wouldn't it be simpler to just accept an object that  
provides the relevant namespace mappings? I originally thought that  
this could be a JSON-style JavaScript object, but it seems to me that  
a DOM node would actually work just as well. Most of the time, you  
want to use the namespace prefixes in effect for the root element, and  
if not, then it is pretty simple to construct a DOM node with all the  
right xmlns declarations. I think this would be better than copying  
the bad NSResolver design from XPath. It would also likely be more  
efficient, and quite possibly less error-prone.

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

I'm not very happy with this because it precludes coming up with a  
better solution than NSResolver.

Regards,
Maciej

Received on Monday, 12 May 2008 10:41:19 UTC