Unfortunately, not in any way that is universally practical. The div:first query is obviously improvable, but when you get into queries like "[EMAIL PROTECTED]" it becomes a lot less clear.
I'll think about improving TAG:first/last - as that seems like a common case, at least. --John On 3/1/07, Yehuda Katz <[EMAIL PROTECTED]> wrote: > This is a smart optimization for :first. John, is this doable? > > -- Yehuda > > > On 3/1/07, Brice Burgess <[EMAIL PROTECTED] > wrote: > > I am searching for the fastest way to fetch the first visible input of a > > page, and currently using: > > $(':input:visible')[0] > > > > I thought this could be improved with the :first selector, and indeed it > > seems so (as it avoids memory assignments for all matched visible > > inputs), so I narrowed it down to: > > $(':input:visible:first')[0] > > > > I wanted to investigate the behavior further, so ran a few small tests > > against http://docs.jquery.com/DOM/Traversing/Selectors > > > > The page was reset/refreshed for each test, and the profiling is being > > done in firebug. > > > > My average results are as follows: > > > > $('*:first')[0]; == 25.014ms, 1168 calls > > $('*')[0]; == 160.382ms, 1159 calls > > > > $('div:first')[0]; == 2.979ms, 122 calls > > > > This leads me to believe that despite the :first limit, all elements are > > found, and then the first one returned. Does any jQuery selector exist > > that *stops* matching after the first match is found? This would avoid > > the n*x extra system calls? > > > > ~ Brice > > > > _______________________________________________ > > jQuery mailing list > > discuss@jquery.com > > http://jquery.com/discuss/ > > > > > > -- > Yehuda Katz > Web Developer | Wycats Designs > (ph) 718.877.1325 > _______________________________________________ > jQuery mailing list > discuss@jquery.com > http://jquery.com/discuss/ > > _______________________________________________ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/