|22 earlier messages|
|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|
|Robin Berjon||May 30, 2006 4:15 pm|
|Jonas Sicking||May 30, 2006 5:56 pm|
|Anne van Kesteren||Jun 5, 2006 2:46 am|
|Anne van Kesteren||Jun 5, 2006 2:49 am|
|Jonas Sicking||Jun 5, 2006 12:31 pm|
|Charles McCathieNevile||Jun 5, 2006 5:37 pm|
|liorean||Jun 5, 2006 6:16 pm|
|Maciej Stachowiak||Jun 5, 2006 10:40 pm|
|Subject:||Re: ACTION-87: Selectors API|
|Date:||May 13, 2006 12:08:26 pm|
On 13/05/06, Anne van Kesteren <ann...@opera.com> wrote:
On Sat, 13 May 2006 05:49:45 +0200, liorean <lior...@gmail.com> 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 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.
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.