Re: [selectors-api] Investigating NSResolver Alternatives

Lachlan Hunt wrote:
> and then if an undefined prefix was used, e.g.
> 
> resolver("math");
> 
> which would then return ns["math"] as undefined.

Hmm.  That's an interesting use case, I agree.

> Is there a reason you made it resolve twice, instead of just remembering 
> the value and reusing it?

It was simpler than creating a new data structure for remembering the value, and 
the performance cost didn't seem particularly high.

>> Your list of use cases does not include "ability to resolve any 
>> namespace prefix in the selector to something (at least '') without 
>> knowing anything about the selector string".  There was one mention of 
>> this as a use case earlier, but I'm not sure whether it's one we care 
>> about.
> 
> I'm not sure what you mean.

Someone mentioned wanting to be able to pass arbitrary strings to querySelector 
to see whether that selector is supported, without knowing what namespaces the 
string uses.  In other words, they wanted a resolver that resolved all prefixes 
to the null namespace.

>> It doesn't seem any more verbose than any other solution here.  Am I 
>> missing something?
> 
> Just that I personally dislike typing JSON syntax. :-)

That's really not the same as "verbose", which is more about number of 
characters... ;)

> I checked in an initial draft with the proposal.  There are still some 
> references to NSResolver hanging around in the spec, but the actual 
> authoring and processing requirements have been specified in section 6.
> 
> http://dev.w3.org/2006/webapi/selectors-api/#nodeselector
> 
> If this isn't going to work, I can easily revert to what it was before.

I'll try to look at this by tomorrow and comment.

-Boris

Received on Saturday, 12 July 2008 16:53:10 UTC