W3C home > Mailing lists > Public > www-style@w3.org > September 2009

Re: Supporting Scoped Selectors in Selectors API 2

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 Sep 2009 19:41:34 -0500
Message-ID: <dd0fbad0909281741q7b2e8ecep8ff5c072137df8b5@mail.gmail.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Cc: www-style <www-style@w3.org>
On Mon, Sep 28, 2009 at 6:49 PM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
> Tab Atkins Jr. wrote:
>> I'm not sure why we needed two separate functions either when a
>> simple [0] tacked to the end of the *All call would work.
> It's less efficient to use the All method when you know you only want the
> first result, since the implemention needs to find all results and create
> the node list only to have it discarded almost immediately.

As discussed over in IRC, I'm not certain that this is a relevant
problem.  The most common case for single-result queries will be
simple "#foo" strings, which an HTML implementation can special-case
into a simple getElementById call for efficiency.  Existing js
selector engines like Sizzle do this already.

In all other cases, existing js selector engines apparently don't feel
this optimization is important enough to expose to their users, even
when they're built on actual DOM-walkers (Sizzle is now built on
querySelectorAll, I believe, when that exists).

Thus I'd suggest that we can get by with only introducing a single new
function (queryScopedSelectorAll, basically).

You correctly pointed out in IRC that this would create an
inconsistent API, though, which does suck.

Received on Tuesday, 29 September 2009 00:42:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:39 UTC