W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-87: Selectors API

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 23 Mar 2006 13:28:19 +0100
To: "Ian Hickson" <ian@hixie.ch>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s6u8xhcv64w2qv@id-c0020.oslo.opera.com>

New draft:  

On Wed, 22 Mar 2006 23:48:51 +0100, Ian Hickson <ian@hixie.ch> wrote:
> New comments:
> The term "first" is not defined (for |match()|). Specifically, it should
> say whether it is the first match in a depth-first pre-order traversal,  
> or
> whether it is a breath-first traversal (depth-first pre-order makes the
> most sense, IMHO).

Used your suggestion.

> "In document order" could be more explicit.

Used the suggestion from Maciej in a follow-up e-mail.

> There is no normative description of how |Function| objects in ECMAScript
> end up supporting XPathNSResolver.

That's in theory in DOM Level 3 XPath. I added an open issue on whether or  
not I (we) want to wait for that draft. In theory Selectors API could  
define XPathNSResolver for the moment. It's not that difficult.

> I don't think "In ECMAScript bindings the nsresolver argument in both
> match and matchAll must be an optional argument." as a requirement makes
> sense. I think it would be better to phrase it as something like "In
> ECMAScript, if the nsresolver argument in an invocation of match() or
> matchAll() is omitted, UAs must handle the invocation as if the  
> nsresolver
> argument was null." or something.

I tried the "or something" part. Let me know how it turned out :-)

> Also, the spec should say what should happen if the nsresolver argument  
> is null.

Added something without conformance criterea... Not to happy about that  
but at the moment I've not really a good idea on how to improve it.

>> > * 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.
> If you really want to not use the term NodeList, I recommend defining
> StaticNodeList as:
>    typedef StaticNodeList NodeList;
> ...rather than duplicating the interface definition.

Used your suggestion. Will remove the open issue after you checked it.

>> > * The spec doesn't say _how_ to resolve the namespaces using the
>> > nsresolver argument.
>> I deferred this to DOM Level 3 XPath now.
> That is a non-normative note. It's also not clear where in that spec it  
> is defined what the requirements on implementations and authors are.

I could probably define it within the draft as suggested above...

>> > * 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?
> Section 5 of Selectors.

Ah, that header currently says "Group_s_ ..." instead of "group". The  
section itself also doesn't really say something like "a <dfn>group of  
selectors</dfn> is a comma-separated list of selectors"...

>> > * 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.
> There are three main reasons. One is that pseudo-elements can in certain
> cases refer to Elements (XBL2 in particular introduces this concept).
> The second reason is that pseudo-elements are perfectly valid selectors,
> so if the script is just running through a list of selectors and checking
> each one for a match, it will not want valid selectors to throw an
> exception. Consider, e.g., if the input is coming from a user -- you want
> to distinguish "doesn't match any elements (because it can't)" from "is
> invalid syntax".
> The selector "foo:not(foo)" will never match anything either, but it
> doesn't raise an exception. You don't want to require the implementation
> to look at the selector any more than it would for a normal CSS
> implementation.
> The third reason is that you could have a selector that contains
> pseudo-elements and yet can match an element, for instance:
>    p, p::first-line
> ...can match an element (p).

Ok, I lifted this and added an informative note.

> Otherwise, looks good.


Anne van Kesteren
Received on Thursday, 23 March 2006 12:28:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC