Lachlan Hunt wrote:
Boris Zbarsky wrote:
Anne van Kesteren wrote:
To ensure that naïve implementors don't overlook the potential
issue here. An implementation of NSResolver can be provided by the
script author as the specification explains and the script author
can do all kinds of weird things that don't match a conforming
implementation of NSResolver (such as mutating the DOM tree).
Is a conforming querySelector implementation allowed to throw an
exception when this happens?
No. It is only allowed to throw an exception when the text says so.
In that case, can you please describe what is a conforming behavior
for a querySelector (or querySelectorAll) implementation if:
1) It needs to call the NSResolver on every match attempt
2) The NSResolver mutates the DOM on every match attempt
That would seem to be a very inefficient implementation, though I
suppose the spec should deal with the possibility in one way or another.
If you're going to require the implementation to "deal" with
NSResolvers which do random stuff but put too many constraints on what
it's allowed to do to deal with them (as you are), you make an
implementation impossible.
Now maybe you're actually requiring that the number of calls to the
NSResolver for any given selector and initial DOM tree is bounded in
the face of all possible mutations by the NSResolver and that hence
the DOM will at some point stabilize and it will be possible to return
the things the spec requires be returned. But if that's a constraint
you want to place on implementations, you should probably spell it out
clearly.
Note that in Gecko I suspect the NSResolver would only be called
during the parsing of the selector, so we could in fact return the
things the spec requires... on the post-mutation DOM, not the
pre-mutation one. It's not clear to me from the spec whether this
would be conformant.
It's not clear to me what the spec should say to resolve this issue. Do
you have any suggestions?
For what it's worth, the DOM-XPath spec more or less dictates that the
NSResolver is only used during parsing of the expression. I think this
is a very acceptable requirement given how much hassle arises if the
implementation were to use the NSResolver were used while executing the
expression.
The exact same applies to the selectors API IMHO.
I.e. I don't see a need to allow an implementation like the one
described by Boris.
/ Jonas
