Thank you for all the suggestions. Yes, we are most definitely looking at
ways to rein in the big select lists, but that won't happen overnight,
unfortunately. I would argue that hundreds of nodes is fairly big, but not
big enough to explain it taking 12+ seconds to process, especially when the
same operation takes a fraction of a second in FF. I would venture to guess
that it has more to do with IE not liking the algorithm used for some
reason.
I did try doing something involving this:
$('textarea,select,[EMAIL PROTECTED]')
and that completely eliminated the performance problem, but it returns the
elements in the order you specified (all textareas, then all selects, then
all inputs) rather than in the order that they appear in the document. I
couldn't come up with a way to compare 2 nodes and determine which comes
first in the document. Comparing their top/left positions is a possibility.
But I think I'm going to do this by looping through form.elements. It's
easy, fast, and appears to have adequate browser support. And even if it
doesn't work in all browsers, I don't consider this "mission-critical"
functionality anyway.
Thanks again for the suggestions.
Todd
On 12/20/06, Dave Methvin <[EMAIL PROTECTED]> wrote:
> Did you perhaps mean filter() instead of select()?
Yep, I meant filter(), thanks for the catch.
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
