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
