|14 earlier messages|
|Maciej Stachowiak||Feb 26, 2006 3:03 pm|
|Jonas Sicking||Feb 28, 2006 1:57 pm|
|Ian Hickson||Mar 6, 2006 12:33 pm|
|Ian Hickson||Mar 6, 2006 12:35 pm|
|Anne van Kesteren||Mar 22, 2006 2:30 am|
|Anne van Kesteren||Mar 22, 2006 2:33 am|
|Anne van Kesteren||Mar 22, 2006 2:35 am|
|mozer||Mar 22, 2006 3:16 am|
|Anne van Kesteren||Mar 22, 2006 3:58 am|
|mozer||Mar 22, 2006 4:30 am|
|Anne van Kesteren||Mar 22, 2006 4:37 am|
|Jim Ley||Mar 22, 2006 5:43 am|
|Anne van Kesteren||Mar 22, 2006 6:08 am|
|Jim Ley||Mar 22, 2006 6:45 am|
|Maciej Stachowiak||Mar 22, 2006 11:16 am|
|Maciej Stachowiak||Mar 22, 2006 11:22 am|
|Maciej Stachowiak||Mar 22, 2006 11:25 am|
|Robin Berjon||Mar 22, 2006 2:01 pm|
|Maciej Stachowiak||Mar 22, 2006 2:28 pm|
|Ian Hickson||Mar 22, 2006 2:48 pm|
|Ian Hickson||Mar 22, 2006 2:51 pm|
|Maciej Stachowiak||Mar 22, 2006 3:20 pm|
|Jim Ley||Mar 22, 2006 6:17 pm|
|Jim Ley||Mar 22, 2006 6:24 pm|
|Anne van Kesteren||Mar 23, 2006 4:28 am|
|Ian Hickson||Mar 23, 2006 2:31 pm|
|Anne van Kesteren||Mar 25, 2006 4:36 am|
|Ian Hickson||Mar 27, 2006 3:13 pm|
|Anne van Kesteren||Apr 3, 2006 5:46 am|
|Anne van Kesteren||Apr 3, 2006 5:51 am|
|liorean||May 12, 2006 8:49 pm|
|Anne van Kesteren||May 13, 2006 4:15 am|
|liorean||May 13, 2006 12:08 pm|
|Anne van Kesteren||May 13, 2006 12:26 pm|
|liorean||May 13, 2006 2:40 pm|
|Anne van Kesteren||May 14, 2006 7:20 am|
|liorean||May 14, 2006 4:22 pm|
|Anne van Kesteren||May 15, 2006 3:15 am|
|liorean||May 16, 2006 9:29 pm|
|Anne van Kesteren||May 17, 2006 5:18 am|
|Lachlan Hunt||May 17, 2006 6:19 am|
|Anne van Kesteren||May 17, 2006 6:30 am|
|Jim Ley||May 17, 2006 6:35 am|
|Lachlan Hunt||May 17, 2006 7:02 am|
|Robin Berjon||May 17, 2006 7:07 am|
|Anne van Kesteren||May 18, 2006 12:46 am|
|Jonas Sicking||May 30, 2006 3:11 pm|
|Jonas Sicking||May 30, 2006 3:24 pm|
|Jonas Sicking||May 30, 2006 3:42 pm|
|Ian Hickson||May 30, 2006 3:55 pm|
|8 later messages|
|Subject:||Re: ACTION-87: Selectors API|
|From:||Anne van Kesteren (ann...@opera.com)|
|Date:||Mar 23, 2006 4:28:19 am|
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 <ia...@hixie.ch> wrote:
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:
...can match an element (p).
Ok, I lifted this and added an informative note.
Otherwise, looks good.