I don't feel too strongly about having both .children and .childElements,
but I do think that .children is a little problematic for authors... they
will always have to check to see if Comment nodes are included, because of
the large marketshare for older versions of IE, while .childElements
3. Obtain a collection of elements based on their relation to more than one
specified reference elements.
e.g.
Query to the document to obtain elements matching :scope+span, where
:scope is intended to match any of the elements in a specific collection.
This would be simpler than iterating
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique elements.
B) A
Not quite. It depends what's being done and which steps need to be
performed and how. AIUI, there are 3 major steps involved here.
1. Obtain a collection of Elements. This could be in one or more
Arrays and/or NodeLists, depending on th.
2. Iteratively execute a selector query on all
My concern with this API is that it forces the implementation to
always sort the array, even if already sorted, and then do a merge
sort on the individual results from querySelectorAll. It would be
faster to simply run the query on each node, and then merge sort the
results.
That's not a
Quick Summary of my opinions:
Matches Selector: Super-super useful - critical, in fact. We're not able to
remove jQuery's selector engine until this is implemented. I'm working with
the devs at Mozilla to get an implementation landed. Already have a test
suite in place.
Filtering
The test suite has been updated accordingly:
http://ejohn.org/apps/selectortest/
http://github.com/jeresig/selectortest/commit/4827dedddaea6fa0b70cfdaadeeafef0d732a753
--John
On Thu, Feb 19, 2009 at 6:40 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Jonas Sicking wrote:
On Wed, Feb 18,
Firefox appears to have some issues that might related to the API, though I
haven't investigated the cause of those yet, so I don't know for sure.
Unfortunately, IE8 can't run John's tests because it relies on some DOM2
features that aren't yet supported, so the testing framework would need
Opera supports publishing this spec as a CR - and if we can get a test suite
and interop report in time, in going for a PR straight away.
Is this a different test suite from the one published here:
http://ejohn.org/apps/selectortest/
http://github.com/jeresig/selectortest/tree/master
Or is it
I just want to note that most browsers implement the .children child element
NodeList (all except for Mozilla-based browsers, at least). I suspect that
building upon this existing work would lead to especially-fast adoption.
--John
- Original Message -
From: Doug Schepers [EMAIL
10 matches
Mail list logo
