I am using this technique to
fix PNG transparency in IE6 (without an HTTP request).

I tried this technique (based on Dean Edwards findings) in several ways in my NWMatcher selector engine to be able to speed up IE browser. I was nearly crying when I realized I couldn’t use that reliably :-)

The trick could work until the number of elements remains low enough (200/300 max). It will start to slow down the browser with more.

@stakka, you are correct, but the “.removeExpression()” can be called within a setTimeout() of 0 milliseconds to achieve the removal of the rules externally from the handler itself. Still I am not sure the process is completely stopped or can be stopped in such a way. I did some test also by enabling/disabling the specific stylesheet containing the expression but not much success either. The only way I found to stop that is to completely overwrite the expression in the rule then remove it.

In IE8 mode this is completely gone, so if it works it will remain a good hack for IE7 and IE6, not applicable for me in a reliable library.

Have fun ! Best Regards.

document.__qsResult.splice(0, document.__qsResult.length);

without overheads. Finally, it seems to be faster via addRule and removeRule, rather than appendChild/removeChild via
var style = document.styleSheets[0] || document.createStyleSheet()

I think we need a lot of test cases but being expressions something not easy to control, behavior speaking, I am not sure how much this technique could be used. The scrollBy is for example something I do not like, but it is necessary, while I have to say this technique could be faster than the one with counters over all nodes.

Regards

Also, as they’re javascript wrapped in css rules, they fail if the user has js turned off so you should still style the element in css alone to allow for a no js scenario.

Any reason why you wouldn’t write this in a js file instead?

This should at least be tested and benchmarked in detail, because while it’s an ugly hack, it it makes IE faster to work with, I’m all for it.

That said, I love how small it is.

Regards

I would use this strategy for a getElementsByClassName rather than querySelector, in that case everything will be more “reasonable” and meaningful.

1) Having to reflow the layout thousands of times.
2) Having to perform the actual processing thousands of times (such as, retrieving the width of the containing element, and performing some type of processing on it)

I don’t believe a reflow of the page is caused by setting a CSS property that doesn’t even register in the browser to 0. And the expense of running the equivalent of “if (true) return 0″ is computationally zero. From my tests there doesn’t appear to be any noticeable performance penalty incurred by this technique.

I don’t know how practical this is for the libraries, but for a “contained” application (like yours) this looks great.

“clear” can overwrite itself, so it’s a good candidate as the helper attribute. And this means it CAN be reused over and over again. So, it might look like this:

.elem {
background-position: inherit;
*clear: expression(
style.backgroundPosition = parentNode.style.backgroundPosition,
style.clear = “none”, 0
);
}

So, clear (with star hack to keep to IE6/7) is used to set the backgroundPosition property to behave as the standard “inherit” from it’s parent object (which IE doesn’t support). Notice the setting of style.clear = “none” is what makes it single-execution. Oh, and some other IE quirk… the final “, 0″ is needed to prevent hanging. crazy.

The problem with the OP method is, as pointed out already, the expression WILL still be evaluated over and over, but just short circuited with the flag. So there’s still overhead.

This property overwrite concept seems a better hack way to achieve the single-execution.