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:  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/draft/selectors-api.htm?content-type=text/html;%20charset=utf-8&rev=1.11


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.

Thanks!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Thursday, 23 March 2006 12:28:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT