Whoa...major problem with IE
Hey guys, I using jQuery on one of the <a href="http://code.google.com">code.google.com</a> pages at work. I am finding that doing a query like this:
jQuery('#gc-toc .selected, ul.gc-topnav-tabs a.selected');
Takes over a second or two on this page, however when I add an id to the .selected node and do the following:
jQuery('#toc-selected, ul.gc-topnav-tabs a.selected');
It executes in roughly 30 or so milliseconds.
<br clear="all">
###UPDATE###
So I tracked the bug down further. It seems that in Internet Explorer, document.getElementById returns elements whose names match as well. What we had, code wise, was something akin to:
<a name="gc-toc"></a>
<div id="gc-toc">....</div>
When jQuery tried to find the selected element within #gc-toc it frantically did some weird stuff and while eventually successful was incredibly slow. Renaming the anchor above it dropped the average time from 2000+ ms to 200ms. Adding the id to the selected node dropped it again to 30 ms or so. This makes sense given how the browsers usually optimize for id'ed elements. I am not sure there is anything you can do other than checking to see if the returned element (when you use
document.getElementById internally) actually has a matching id attribute and if it doesn't using a more drastic searching method. I'd hope this is localized to Internet Explorer (based on the times returned by FireFox and Safari I'd imagine that's true).
<u>Here are times for alternate selector queries when the anchor and the div share both a name and id (respectively).
</u>
div#gc-toc .selected, ul.gc-topnav-tabs a.selected => 2328ms
*[@id="gc-toc"] .selected,
ul.gc-topnav-tabs a.selected => 2437ms
div[@id="gc-toc"] .selected, ul.gc-topnav-tabs a.selected => 312ms
--
Sincerely,
Gabriel Harrison
<a href="mailto:gharrison@google.com">gharrison@google.com
</a>
jQuery('#gc-toc .selected, ul.gc-topnav-tabs a.selected');
Takes over a second or two on this page, however when I add an id to the .selected node and do the following:
jQuery('#toc-selected, ul.gc-topnav-tabs a.selected');
It executes in roughly 30 or so milliseconds.
<br clear="all">
###UPDATE###
So I tracked the bug down further. It seems that in Internet Explorer, document.getElementById returns elements whose names match as well. What we had, code wise, was something akin to:
<a name="gc-toc"></a>
<div id="gc-toc">....</div>
When jQuery tried to find the selected element within #gc-toc it frantically did some weird stuff and while eventually successful was incredibly slow. Renaming the anchor above it dropped the average time from 2000+ ms to 200ms. Adding the id to the selected node dropped it again to 30 ms or so. This makes sense given how the browsers usually optimize for id'ed elements. I am not sure there is anything you can do other than checking to see if the returned element (when you use
document.getElementById internally) actually has a matching id attribute and if it doesn't using a more drastic searching method. I'd hope this is localized to Internet Explorer (based on the times returned by FireFox and Safari I'd imagine that's true).
<u>Here are times for alternate selector queries when the anchor and the div share both a name and id (respectively).
</u>
div#gc-toc .selected, ul.gc-topnav-tabs a.selected => 2328ms
*[@id="gc-toc"] .selected,
ul.gc-topnav-tabs a.selected => 2437ms
div[@id="gc-toc"] .selected, ul.gc-topnav-tabs a.selected => 312ms
--
Sincerely,
Gabriel Harrison
<a href="mailto:gharrison@google.com">gharrison@google.com
</a>
Topic Participants
nyteshade
John Resig
Dave Methvin
sam.collett