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
