atom feed72 messages in org.w3.public-webapiRe: ACTION-87: Selectors API
FromSent OnAttachments
9 earlier messages
Cameron McCormackFeb 25, 2006 5:01 pm 
Daniel SchierbeckFeb 25, 2006 5:25 pm 
Anne van KesterenFeb 26, 2006 2:21 am 
Cameron McCormackFeb 26, 2006 2:33 am 
Cameron McCormackFeb 26, 2006 1:04 pm 
Maciej StachowiakFeb 26, 2006 3:03 pm 
Jonas SickingFeb 28, 2006 1:57 pm 
Ian HicksonMar 6, 2006 12:33 pm 
Ian HicksonMar 6, 2006 12:35 pm 
Anne van KesterenMar 22, 2006 2:30 am 
Anne van KesterenMar 22, 2006 2:33 am 
Anne van KesterenMar 22, 2006 2:35 am 
mozerMar 22, 2006 3:16 am 
Anne van KesterenMar 22, 2006 3:58 am 
mozerMar 22, 2006 4:30 am 
Anne van KesterenMar 22, 2006 4:37 am 
Jim LeyMar 22, 2006 5:43 am 
Anne van KesterenMar 22, 2006 6:08 am 
Jim LeyMar 22, 2006 6:45 am 
Maciej StachowiakMar 22, 2006 11:16 am 
Maciej StachowiakMar 22, 2006 11:22 am 
Maciej StachowiakMar 22, 2006 11:25 am 
Robin BerjonMar 22, 2006 2:01 pm 
Maciej StachowiakMar 22, 2006 2:28 pm 
Ian HicksonMar 22, 2006 2:48 pm 
Ian HicksonMar 22, 2006 2:51 pm 
Maciej StachowiakMar 22, 2006 3:20 pm 
Jim LeyMar 22, 2006 6:17 pm 
Jim LeyMar 22, 2006 6:24 pm 
Anne van KesterenMar 23, 2006 4:28 am 
Ian HicksonMar 23, 2006 2:31 pm 
Anne van KesterenMar 25, 2006 4:36 am 
Ian HicksonMar 27, 2006 3:13 pm 
Anne van KesterenApr 3, 2006 5:46 am 
Anne van KesterenApr 3, 2006 5:51 am 
lioreanMay 12, 2006 8:49 pm 
Anne van KesterenMay 13, 2006 4:15 am 
lioreanMay 13, 2006 12:08 pm 
Anne van KesterenMay 13, 2006 12:26 pm 
lioreanMay 13, 2006 2:40 pm 
Anne van KesterenMay 14, 2006 7:20 am 
lioreanMay 14, 2006 4:22 pm 
Anne van KesterenMay 15, 2006 3:15 am 
lioreanMay 16, 2006 9:29 pm 
Anne van KesterenMay 17, 2006 5:18 am 
Lachlan HuntMay 17, 2006 6:19 am 
Anne van KesterenMay 17, 2006 6:30 am 
Jim LeyMay 17, 2006 6:35 am 
Lachlan HuntMay 17, 2006 7:02 am 
Robin BerjonMay 17, 2006 7:07 am 
13 later messages
Subject:Re: ACTION-87: Selectors API
From:Ian Hickson (ia@hixie.ch)
Date:Mar 22, 2006 2:48:51 pm
List:org.w3.public-webapi

On Wed, 22 Mar 2006, Anne van Kesteren 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).

"In document order" could be more explicit.

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

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. That text sucks but the point is that the requirement is on the UA, and the requirement clearly states what must happen. As currently phrased, the spec doesn't say what it means for the argument to be optional.

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

* 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.

* 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.

The API supports namespaces. That makes it more complicated, whether or not the author can omit the namespace argument.

* 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.

* 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.

* 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).

Otherwise, looks good.