End of the road?
My long-time readers may remember that, back in the early days, ADxMenu had two versions. One that used .htc file and only one set of styles and the other that used only javascript but two sets of styles. The reason was that .htc version at that time used original Peter Nederlof’s csshover.htc which went through entire document looking for elements to apply :hover trickery and thus had far from good performance on very long pages.
Things changed when I recoded it to work only with menu elements and ADxMenu 3 utilized it to its fullest potential.
However, performance issues are not defeated yet. In the last project I’m working on, I have three menus on one page and two of them are very large. The page itself also features a great deal of various positioning, using both floats and pos/abs position. Accompanied with these three menus, this brings IE to its knees - it takes him 4-5s on P4-2.8GHz with half-gig of RAM to render that page and execute the .htc. 90% of that freeze time goes on .htc processing.
But not only that. Since my css applies position:relative on li:hover and thus does the actual positioning in that moment, re-rendering of the page takes some time and going from one menu option to another has a very noticeable lag. Last time I have seen such behavior was with Netscape Navigator 4. Sigh…
I created test page with completely stripped-down page leaving just menus where you can still notice the lag, both on page load and when traversing the left-hand menus - for a fraction of second you can see the busy cursor popping up. The numeric value in the middle is how long it takes IE to complete the .htc processing. And than imagine how this looks like when Sports menu has 3x more items (as is the case on production environment).
I spent entire afternoon, measuring where is all this time spent. It appears that each _currentStyle_.addRule call takes about 50-60ms, and some 1s is lost on function calls overhead. I don’t see a solution with .htc anymore as it seems that IE’s Trident engine has its limits. Pages that use heavy positioning are simply not what IE can handle well. I could be wrong, but the more positioning I add, the less responsive it becomes.
It is time for different IE strategy. I could easily end up dumping .htc all together and go back to Javascript and delayed initialization. This could prove to be a good thing after all.
For those interested, I resolved the perfomance problem by completly removing .htc, rewriting the design rules so that none of them used li:hover and execute this script on window.onload:
xGetElementsByClassName("adxm", document, "ul", function(oUL) {
xGetElementsByClassName("submenu", oUL, "li", function(oLI) {
oLI.onmouseover = function() {
if (!this.UL)
this.UL = oLI.getElementsByTagName("ul")[0];
this.UL.style.visibility = "visible";
}
oLI.onmouseout = function() {
this.UL.style.visibility = "hidden";
}
} );
} );
And this works near instant.