On 13/05/06, Anne van Kesteren <ann...@opera.com> wrote:

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.

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.

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 selectors.search(document) 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.

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, Array.prototype.map 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:http://liorean.web-graphics.com/>