I ended up just removing the indexOf code in favor of using ranges -
seems to work well!
--John
On Tue, Feb 17, 2009 at 2:59 AM, Robert Katić wrote:
>
> To ensure order and uniqueness with XML and non current documents too,
> we have to ensure that the NodeList "allSort" is the correct one.
>
I founded an error in my code.
Instead of
array.splice(i--, 1);
goes
array.splice(i, 1);
On Feb 17, 8:59 am, Robert Katić wrote:
> To ensure order and uniqueness with XML and non current documents too,
> we have to ensure that the NodeList "allSort" is the correct one.
> Maybe something l
To ensure order and uniqueness with XML and non current documents too,
we have to ensure that the NodeList "allSort" is the correct one.
Maybe something like this:
function sortNodes( array ) {
if ( array.length === 0 )
return;
if ( allSort && allSort._document !=
> So, if I understand you, the third argument is exposed to the API but
> not like an set that will be filled with additional query, but like an
> simple array which the new elements will be simply appended.
> So if the user would use the third argument, later, he will eventually
> resort and remo
So, if I understand you, the third argument is exposed to the API but
not like an set that will be filled with additional query, but like an
simple array which the new elements will be simply appended.
So if the user would use the third argument, later, he will eventually
resort and removes the du
> I know, but adding other elements to the results (given as argument)
> will probably make the results array unsorted (even with duplicates).
I think there's a disconnect here. When there isn't multiple arguments
(e.g "a.foo") there are no duplicates or sorting problems - that's
implicit in the
Maybe I was not clear. I don't think it is wrong to live results
unsorted if given as argument (if it was planed), but then we can take
this in consideration to do optimizations...
On Feb 16, 2:53 pm, Robert Katić wrote:
> I know, but adding other elements to the results (given as argument)
> wi
I know, but adding other elements to the results (given as argument)
will probably make the results array unsorted (even with duplicates).
On Feb 16, 2:47 pm, John Resig wrote:
> > Hm, how implemented, usage of the third argument would not guarantee
> > that the results will be sorted.
> > Take
> Hm, how implemented, usage of the third argument would not guarantee
> that the results will be sorted.
> Take for example: Sizzle('foo.barr', null, anArray) - there is no
> extra selector, so no sorting too.
That's fine - since selectors that don't have a comma in them are
already in document
Hm, how implemented, usage of the third argument would not guarantee
that the results will be sorted.
Take for example: Sizzle('foo.barr', null, anArray) - there is no
extra selector, so no sorting too.
On Feb 16, 2:22 pm, John Resig wrote:
> > If I am right, with this implementation, with "a, b
> If I am right, with this implementation, with "a, b, c" the results
> will be sorted twice.
> If so, would it be enough to replace line 115 with this one?
>
> if ( sortOrder && !arguments[2] ) {
>
> Maybe it looks dirty... but anyway sorting is not an cheap
> operation...
That wouldn't be suffi
If I am right, with this implementation, with "a, b, c" the results
will be sorted twice.
If so, would it be enough to replace line 115 with this one?
if ( sortOrder && !arguments[2] ) {
Maybe it looks dirty... but anyway sorting is not an cheap
operation...
On Feb 14, 6:14 pm, John Resig wro
Looks fine to me. Thx.
On Feb 14, 7:11 pm, John Resig wrote:
> > Nice job John, I like your solution very much.
>
> Thanks!
>
> > But if I am right, the querySelectorAll will always fall with no
> > standard filters, so we have to ensure order and uniqueness on all
> > browsers (?).
>
> Ah - so
Looks fine to me. Thx.
On Feb 14, 7:11 pm, John Resig wrote:
> > Nice job John, I like your solution very much.
>
> Thanks!
>
> > But if I am right, the querySelectorAll will always fall with no
> > standard filters, so we have to ensure order and uniqueness on all
> > browsers (?).
>
> Ah - so
Looks fine to me. Thx.
On Feb 14, 7:11 pm, John Resig wrote:
> > Nice job John, I like your solution very much.
>
> Thanks!
>
> > But if I am right, the querySelectorAll will always fall with no
> > standard filters, so we have to ensure order and uniqueness on all
> > browsers (?).
>
> Ah - so
> Nice job John, I like your solution very much.
Thanks!
> But if I am right, the querySelectorAll will always fall with no
> standard filters, so we have to ensure order and uniqueness on all
> browsers (?).
Ah - so you mean the case where someone does: "div:first, p:first"
Hmm - good point.
Nice job John, I like your solution very much.
But if I am right, the querySelectorAll will always fall with no
standard filters, so we have to ensure order and uniqueness on all
browsers (?).
On Feb 14, 6:14 pm, John Resig wrote:
> So I'm looking at your code - it looks pretty good - but it c
So I'm looking at your code - it looks pretty good - but it can enjoy
from a huge optimization. The precedes method has 3 possible states.
sourceIndex: Available in IE
compareDocumentPosition: Available in Firefox, Opera, and WebKit Nightlies
other: Safari/Chrome
Now the "problem" is the other "
Reasons why maybe an joinResults would be better/faster instead of an
sort are this:
1) Single selector (without comma) will easily return nodes in
document order and with no duplicates, so we have not to worry about
single selector results order and duplicates.
2) If we sort the final array we
Robert,
I have also needed this bit of help from jQuery...for extracting texts
from HTML code.
I proposed this similar solution on the Sizzle group some time ago:
http://groups.google.com/group/sizzlejs/browse_thread/thread/44d2b3fd5d532b5b
which probably solves with a simpler sort() on the
I corrected the joinResultsHelper:
function joinResultsHelper( res, a, i, b, j ) {
if ( b && b[j] ) {
for ( var l = a.length; i < l; ++i ) {
if ( a[i] === b[j] && !b[++j] )
return joinResultsHelper( res, a, i )
else if ( precedes(a[i], b[j]) )
21 matches
Mail list logo