Re: ACTION-87: Selectors API

Hi Anne and al.

Some precisions

in spec could we replace "selector" by "selectors" because of it is a "group
of selector" ?

little typo miss a space after MUST in

"The match method, when invoked, *must* return the first Element that
matches the group of selectors (selector), if any. Otherwise it *must*return
null."

"if the given selector selector is an invalid selector or "
should be replaced by
"if the given group of selectors selector(s) contain an invalid selector
or"...

Mohamed Zergaoui, Innovimax

On 3/22/06, Anne van Kesteren <annevk@opera.com> wrote:
>
>
> 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/>
>
>
>