Thanks Karl.  I did something similar in the end adding a new custom
selector prefixed with the ":", like:
"jQuery(a).is('.classOne') || jQuery(a).is('.classTwo')"
However, yours looks like it would execute faster and more
efficiently, so I'll probably switch to using that.

All aside though, is the rationale here performance?  Or is this just
how it was implemented and no one has proposed otherwise?

Perhaps I'm foolishly getting ahead of myself here, but the while loop
around 1241 in find() seems to explain why this happens, is there any
way of modifying find() so that it searches comma separated selector
returning the results in DOM order?  Or am I dreaming here? :)  I'm
especially wondering if this has been tried before and then discarded
because of speed/performance issues.

Pax,
- Stan


On Nov 22, 10:53 pm, Karl Swedberg <[EMAIL PROTECTED]> wrote:
> Hi Stan,
>
> this topic has come up once before at least, and I can definitely  
> understand the confusion. The conciseness of the syntax in this case  
> perhaps leads to unexpected results. I'm not sure what the rationale  
> is, but using a filter function should give you the results in the  
> order you want them. Something like this maybe?
>
> $('div').filter(function() {
>         return this.className.match(/classOne|classTwo/);
>
> })
>
> That should give you the divs in the order they appear in the DOM.
>
> Cheers,
>
> --Karl
>
> On Nov 22, 2007, at 10:19 PM, Stosh wrote:
>
>
>
> > Greetings,
> > I have a general inquiry for the core dev guys...  I noticed today
> > while running a selector that comma separated selectors build their
> > results by order of the selector and not by order they appear within
> > the originating DOM.  What I mean is, if I am running a selector that
> > has say two different classes and I want nodes for both (ie.
> > div.classOne and div.classTwo) I might run $
> > (start).find('div.classOne, div.classTwo).  My expectation when I did
> > this was that returned nodes would come in order of their appearance
> > in the DOM, but instead the children matching div.classOne are found,
> > and then the children for div.classTwo are found afterwards, even
> > though they might appear in an order like this for example:
> > [div.classOne, div.classTwo, div.classOne, div.classOne,
> > div.classTwo].  What is the rationale behind running these selectors
> > this way?  Is this something that could be altered with a different
> > syntax via a plugin or something like that?  The only reason I even
> > noticed this is because I ran the results through $.each() and needed
> > to deal with the nodes in their appearance.  I wound up figuring out a
> > work around in the end for my particular situation, but this struck me
> > as worth inquiring about.
>
> > Anyhow, thanks in advance for any responses/replies/feedback on this
> > one.
>
> > Pax,
> > - Stan Lemon

Reply via email to