W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [selectors-api] Summary of Feature Requests for v2

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 23 Sep 2009 18:58:09 -0700
Message-ID: <c9e12660909231858v78943fd8g7a44760facdbdaf4@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: public-webapps <public-webapps@w3.org>
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Hi,
>  I'm planning to look at beginning work on Selectors API v2 soon to add a
> number of requested features that didn't make it into the first version.
>  This e-mail is a summary of what is being considered, and is intended to
> start discussion about which ones are really worth focussing on, and how to
> ensure they address the use cases appropriately.
>
>
> *Matches Selector*
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

That helps event delegation pattern. That is, adding an event handler
to a container and then inspecting the event's target, to see if what
the user interacted with (and what the program should do about it).
This approach tends to be a much more efficient pattern than
traversing through the entire document to match nodes, and then add
event handler callbacks to them.

The existing draft encourages less efficient programming style of
traversing through the document. Pity.

>
> The suggestion is for being able to check if a given element matches a given
> selector.  There is already similar functionality provided by JQuery and
> Mozilla have begun working on an implementation for it in Firefox.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865

>
> For the basic case, this is fairly trivial.  The method just needs to take a
> selector and evaluate it against the element, and return true or false.
>
> But considering the proposed :scope pseudo-class that has been previously
> discussed here and in the CSS WG, it might also be nice to check if the
> element matches the selector in relation to a specified reference element.
>
> For example, given 2 elements, div1 and div2, you could check if div2 is a
> sibling of div1 like this:
>
> div2.matchesSelector(":scope~div", div1);
>

The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.

A function to get an actual Selector object would allow the program to
creating a cached matcher.

var selector = QuerySelector.create("div.panel");
var isPanel = selector.matches(event.target);

Garrett
Received on Thursday, 24 September 2009 01:58:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT