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
