Re: ACTION-87: Selectors API

On 13/05/06, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 13 May 2006 05:49:45 +0200, liorean <liorean@gmail.com> wrote:
> > I've written some commentary on the Selectors API draft on WebGraphics.
> >
> > <uri:http://web-graphics.com/2006/05/12/javascript-and-selectors/>
>
> 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.

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/>

Received on Saturday, 13 May 2006 19:08:33 UTC