Friday, October 17, 2008

One-time execution of IE CSS expressions

You know guys, CSS expressions in IE (6 and 7) is a nice and powerful tool, which offers an excellent way to overcome compatibility issues. Dozens of missing W3C features can be emulated simply by an expression. It's so elegant and comfortable to solve the issues of lack of standards with them. You can make behaviours for :first-child, max-height, :hover, cellspacing/cellpadding, different kinds of selector operators etc. Ok, we know that, but hey, they say at Yahoo that CSS expressions are nasty, they want me to avoid them and instead use javascript. Yahoo says that expressions are evaluated so frequently that that is untenable. Well, the fact is, he's right.

But I love expressions.

Last time, I wanted to use the inherit value, which is not supported in IE6/7. Pretty tiny problem, the solution is:
.elem {
background-position: expression(parentNode.style.backgroundPosition);
}
The place where class .elem elements appeared was deeply in a tag soup of a complex menu, where some layered CSS sprites inherited the containers background-position, so it was a hit on the responsiveness of the menu hover effect, of course. It got executed on every mouse movement for every menu item in the structure and, overall, thousands times in some seconds.

What to do now. Yahoo says: „One way to reduce the number of times your CSS expression is evaluated is to use one-time expressions, where the first time the expression is evaluated it sets the style property to an explicit value, which replaces the CSS expression.” This sounds exciting, but don't know how to do that. To put it short, someone asks about this in the comments in the above linked Yahoo page, and Steve Souders answers with a link to a testpage. He calls an external function in the expression which function then sets the element's style property:
<script>
function setOnetimeBgcolor(elem) {
elem.style.backgroundColor = <some calculation>;
}
</script>
<style>
P {
background-color: expression(setOnetimeBgcolor(this));
}
</style>
This can be rewritten in one expression:
/* It works. */
P {
background-color: expression(
new Function('elem', 'elem.style.backgroundColor = <some calculation>;')(this)
);
}
Here we are, this works. The expression will be evaluated only one time. Now comes the interesting part. When I copied this solution in my working context to emulate inherit on the background-position property, it didn't work:
/* WON'T WORK */
.elem {
background-position: expression(
new Function('e', 'e.style.backgroundPosition = e.parentNode.style.backgroundPosition;')(this)
);
}
The inherit behaviour itself was live, but it was as terribly sluggish as before. I made a test with a counter and it turned out that the expression actually didn't overwrite itself and was getting evaluated continuously. The method failed. But why does it work on Steve Souders' example page?

After some debugging I've found that, unlike background-color, a background-position expression can't overwrite itself with a static value. It seems that CSS properties differ in the manner of which one of them can or cannot overwrite themselves. For example, background-color can. Display can. Background-position can't. Float and height also can't, but clear can...!

Very interesting, but it's the very truth.

So now I took an 'assistance' property which is self-overwritable, let this be clear. Watch it, it's only used as a dummy assistance property. Then set the value of background-position in it, which is not self-overwritable, and lastly overwrote the assistance property. This trick even allows us to avoid function creation:
.elem {
background-position: inherit;
*clear: expression(
style.backgroundPosition = parentNode.style.backgroundPosition,
style.clear = "none"
/* debug: */
, window.expc = window.expc || 0,
window.defaultStatus = expc++
);
}
This is it. The menu was absolutely responsive. The expression runs only one time. You can experiment, the debug lines show the number of executions in the browser's status bar. I think it is the recommended way of CSS expression usage with any CSS property, when working around compatibility issues.

It's important to note that you cannot use the underscore hack (_clear) in case of expressions intented only for IE6, because it will run on IE7 too. In such situations you have to separate it by other ways.

UPDATE

Yet, it's still not the end, there's another catch. If you remove the debug lines from the above example, IE gently will hang up. Put a simple value, e.g. a 0 in place of that, and it will work:
/* Final example, the ultimate way of writing one-time CSS expressions */

.elem {

/* we want to implement the unsupported 'inherit' value */
background-position: inherit;

/* 'clear' is a dummy property */
*clear: expression(

/* this is the actual assignment */
style.backgroundPosition = parentNode.style.backgroundPosition,

/* overwriting dummy property, 0 needed to avoid crash */
style.clear = "none", 0
);
}

10 comments:

  1. Any script execution at the Style Sheet stack of the browser is a performance issue and more importantly a security threat.

    Good news is Microsoft is ending expressions in Internet Explorer as announced on Thursday earlier this week.

    A very nice move towards the standard-compliant browser.

    ReplyDelete
  2. Furthermore, any script execution at all is a performance issue and more importantly a security threat.

    ReplyDelete
  3. Nice job, this is exactly what I was looking for.

    While expressions aren't ideal, they can still be useful at times. For example, if you want to use properties like "max-width:" which is supported by IE7 but not IE6. You can segregate expressions by using conditional statements to prevent users in IE7 from experiencing any security or performance issues.

    Users in IE6 should be fairly familiar with it's security and performance issues by now anyway, it's over 7 years old.

    ReplyDelete
  4. I wouldn't think we should talk about that blurred 'security issue' topic in this case, as the one who writes the expressions is you, the author of the site. Further on this logic, web developer himself is the biggest security issue in a site.

    ReplyDelete
  5. When you want to target IE6 and not IE7 precede the expression with a hyphen followed by a dollar sign. For example, -$clear:expression( )

    ReplyDelete
  6. Any idea what other properties would be able to be used. I would like to not use clear as it could have a use for other things. Prehaps zoom. seeing as how this is an i.e only propertiy anyway.

    ReplyDelete
  7. Nice hint with a -$ thing.

    Anonymous: give some a shot, and share your experiences :)

    ReplyDelete
  8. Hey, thanks for the post. I'm only starting work on CSS, so it's great finding examples like these online, and comments to help me understand things better. Thanks! :)

    ReplyDelete
  9. "It's important to note that you cannot use the underscore hack (_clear) in case of expressions intented only for IE6, because it will run on IE7 too."
    Are you sure?
    _property seems to be filtering out IE7

    ReplyDelete
  10. IE7 just won't match it with the related CSS property, thus won't apply (unlike IE6). But both browsers WILL process it. So if you use expressions to inject code with underscore, it will behave the same. Test it.

    In other words, underscore doesn't get filtered out in parsing phase, * does.

    ReplyDelete