On 20/10/11 7:32 PM, Jonas Sicking wrote:
On Thu, Oct 20, 2011 at 1:14 AM, Sean Hogan<shogu...@westnet.com.au> wrote:
On 20/10/11 1:07 PM, Jonas Sicking wrote:
On Tue, Oct 18, 2011 at 9:42 AM, Alex Russell<slightly...@google.com>
wrote:
Lachlan and I have been having an...um...*spirited* twitter discussion
regarding querySelectorAll, the (deceased?) queryScopedSelectorAll,
and ":scope". He asked me to continue here, so I'll try to keep it
short:
The rooted forms of "querySelector" and "querySelectorAll" are
mis-designed.
I'd like to instead propose that we
shorten all of this up and kill both stones by introducing a new API
pair, "find" and "findAll", that are rooted as JS devs expect. The
above becomes:
element.findAll("> div> .thinger");
I like the general idea here.
I think appropriate optimizations as well as extensible functions
should be out-of-scope for this thread. They are both big subjects on
their own and we're approaching 50 emails in this thread.
If find / findAll are added to the spec there should also be an equivalent
of matchesSelector that handles implicitly scoped selector, e.g. "> div>
.thinger". To aid discussion I will call this matches(), but I don't think
it is a good final choice.
How would .matches() work? For .findAll we basically prepend a ":scope
" selector step where the :scope pseudo-class matches the element on
which .findAll was called.
If we did the same for .matches() then
elem.matches("foo")
would try to match elem against the selector ":scope foo" where
":scope" only matches elem and thus the selector only matches elements
which are descendants of the element on which .matches() was called.
In other words, .matches() would never match anything.
Clearly you must have some other behavior in mind as a function which
always returns false isn't particularly interesting.
/ Jonas
See the definition of matchesSelector(selector, [ refNodes ]) in the spec:
http://www.w3.org/TR/selectors-api2/#matchtesting
