- From: Anne van Kesteren <annevk@opera.com>
- Date: Sat, 13 May 2006 21:26:54 +0200
- To: "Web APIs WG (public)" <public-webapi@w3.org>
On Sat, 13 May 2006 21:08:26 +0200, liorean <liorean@gmail.com> wrote: > 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. The Selectors specification doesn't define scoped selectors as noted in "Outstanding Issues." Not sure if this specification should define that for them. This has been noted though. I'm not really decided about the more general issue: A group of selectors becoming some kind of object instead of a string. I can see it would have some advantages for the simple use cases this draft was written for it's not really needed. >> 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, 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. Well, if StaticNodeList looks that way NodeList would look that way too and I'd therefore suggest raising that on www-dom@w3.org instead. Note that I don't really want to be defining StaticNodeList in the first place. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Saturday, 13 May 2006 19:27:04 UTC