atom feed72 messages in org.w3.public-webapiRe: ACTION-87: Selectors API
FromSent OnAttachments
22 earlier messages
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 
Anne van KesterenMay 18, 2006 12:46 am 
Jonas SickingMay 30, 2006 3:11 pm 
Jonas SickingMay 30, 2006 3:24 pm 
Jonas SickingMay 30, 2006 3:42 pm 
Ian HicksonMay 30, 2006 3:55 pm 
Robin BerjonMay 30, 2006 4:15 pm 
Jonas SickingMay 30, 2006 5:56 pm 
Anne van KesterenJun 5, 2006 2:46 am 
Anne van KesterenJun 5, 2006 2:49 am 
Jonas SickingJun 5, 2006 12:31 pm 
Charles McCathieNevileJun 5, 2006 5:37 pm 
lioreanJun 5, 2006 6:16 pm 
Maciej StachowiakJun 5, 2006 10:40 pm 
Subject:Re: ACTION-87: Selectors API
From:liorean (
Date:May 13, 2006 12:08:26 pm

On 13/05/06, Anne van Kesteren <> wrote:

On Sat, 13 May 2006 05:49:45 +0200, liorean <> wrote:

I've written some commentary on the Selectors API draft on WebGraphics.


1. I'm aware how selectors work in browsers and that that's different from how they'd work here, but there was no pushback from implementors given that this is something authors want to use.

Actually, a large part of that blog entry was written more to the WebGraphics audience than to you. I trust you know how these things work in browsers quite a bit more in detail than I do.

Note also that you don't get live collections.

Might be, I have only a little knowledge of how they are implemented in browsers. I can see a number of different solutions to how you could implement them, depending a bit on whether they have to be thread safe or not.

However, I do know Jens Lindström's explanation of how Opera does them not as actual lists but as filters for the node tree, doing traversal from first, last, or last returned node.

2. I'm not convinced it should be a native data type in ECMAScript. It operates on the DOM which is not native to ECMAScript either. Having an object which implements some selector interface on which you can perform node tests seems like an interesting idea, but is currently outside the scope of this specification. If there is enough interest though it seems certainly we should look into.

Well a DOM node might not be cunstrucable using the following:

var nd = new Node();

But DOM nodes do exist as first class objects in ECMAScript. I couldn't care less about whether it's DOMImplementation.createSelectors(string,nsresolver) or new Selectors(string,nsresolver), but I do think they should be first class objects that are not bound to the document.

I'm more saying this because I think it makes more sense to build an object from the selectors string and the nsresolver once, and reuse that object, than to reevaluate the selector every time you have to use it.

Also, I'm not arguing for any specific way of applying them. document.match(selectors) or isn't important to me. I just wrote it as methods on the selectors object because then searching subtree could take a node which is either a document or an element with one single interface definition, instead of having to replicate the same on both document and element interfaces.

I do think you're unnecessarily limiting the use of the Selectors API in the current draft by only allowing selector matching on the subtree of the document node though. The same way you might want to use getElementsByTagName not on the document node but on some deeper element node, you might want to do selectors matching on the subtree of a deeper element node instead of on the entire tree.

3. Letting StaticNodeList inherit from Array and NodeList not is not an option. They have to be identical. Hopefully DOM Level 3 Core gets errata to say that only some object implementing the NodeList interface is live and not all objects implementing NodeList (well, it currently says something even vaguer if I remember correctly) so we can drop StaticNodeList and just define that the object is static.

Well, does it matter if StaticNodeList in the ECMAScript bindings is defined to have the Array.prototype as it's prototype object instead of the Object.prototype? That doesn't change the interface itself, it's just a question of ECMAScript bindings. The reason one would want this is of course that one might want to use array methods such as Array.prototype.sort, or Array.prototype.filter on the returns from the selector match without having to jump through hoops to do so. At least the ECMAScript defined Array.prototype methods are written to be generic and work on any array-like object, I hope the Mozilla JavaScript 1.6 Array extras are written that way too. And StaticNodeList looks to me to be pretty array-like. -- David "liorean" Andersson <uri:>