Hi Ian,
Thanks for your comments.
A new draft can be found here:
<http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/draft/selectors-api.htm?rev=1.2>
> Comments on the draft:
>
> * It makes no sense for the UA to implement an interface. Objects that
> the UA exposes implement interfaces, not UAs.
Should be fixed.
> * The UA doesn't need to expose an object that implements the NSResolver,
> only the author does.
Should be fixed.
> * Having an interface doesn't imply behaviour -- e.g. NodeList doesn't
> imply that NodeList is live. You can have an object that implemnets
> NodeList and is not live.
DOM Level 3 Core says it's live. Per discussion on public #webapi I see
that is suboptimal and if DOM Level 3 Core gets errata to make that more
clear I'll reconsider it.
> * IMHO getElementsBySelector() should return a live list, just like
> getElementsByTagName.
Implementors disliked that idea. You now agree with them, not?
> * I would recommend against supporting namespaces in the first version,
> for simplicity.
I agree that they are probably not that much needed by authors. Therefore
the argument is optional in ECMAScript bindings so it doesn't harm the
scenario were people probably use it the most.
> * I would recommend having getElementsBySelector and
> getElementsBySelectorNS if you wanted to support both, rather than using
> optional arguments. Some languages don't support method overloading on
> argument signatures and would need different numbers of arguments anyway.
In those languages the second argument is simply required.
> * There is no actual conformance criteria for what should happen when the
> getElementsBySelector method is invoked (the spec says "returns" not
> "must, when invoked, return").
Used the "suggested" language, thanks.
> * The spec doesn't say _how_ to resolve the namespaces using the
> nsresolver argument.
I deferred this to DOM Level 3 XPath now.
> * IMHO the argument to getElementsBySelector should be a "group of
> selectors" not a "selector" (using Selectors terminology).
Used this terminology although I don't really see the Selectors draft
defining this term (using <dfn> or whatever). Could you please point it
out?
> * IMHO the method should not raise an exception when the selector
> contains a pseudo-element. It should would return an empty list.
Given that it per definition only returns Element nodes I don't see why it
shouldn't raise an exception.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>