Gim crack’d

How to: fade text in Internet Explorer 7 while preserving ClearType

I think I figured something new out this week. Excuse me, gentle readers, while I geek out; I promise my next blog post will be about love.

So: fading text in and out is troublesome on Internet Explorer, because it doesn’t support the CSS 3 property opacity, which is a simple way of setting the opacity of an element. An opacity value of 1 means it’s fully opaque, 0.5 means half-transparent, and 0 means invisible. Very easy.

Of course IE doesn’t do this. Instead it has its own mechanism called filters. Nobody uses these because they’re only supported in IE, and a lot of them are kind of dumb anyway — but there is a filter that simply applies an opacity to an element, just like the CSS 3 property. It’s called alpha, which more or less works except for one small bug.

Fantastic! So to fade an element in, you modify both its opacity style and its alpha, and things work themselves out on their own. One last problem. Any text you fade in IE 7 stops being anti-aliased.

Show me (broken in IE 7 only)

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nunc sit amet felis. Sed purus diam, euismod accumsan, suscipit non, volutpat ut, urna. Pellentesque tellus. Maecenas in lacus. Fusce sem nisl, laoreet vitae, laoreet sed, lobortis sit amet, nisl. Mauris tincidunt semper nisi. Sed in lorem eu nulla condimentum dignissim. Vestibulum convallis justo et quam. Sed enim. Nam eget ipsum eu mi facilisis interdum. Etiam eros elit, vestibulum quis, pellentesque vitae, auctor ac, purus.

The problem is that as soon as you apply a filter to an element in IE 7, it is no longer anti-aliased (aka displayed with ClearType). This is intentional, but I think it’s a bad idea. Of course there are readability issues with half-translucent text! But once the transition is over, you still lose anti-aliasing, and you can’t get it back. Clearing the filter after the transition doesn’t do anything. The Mark of the Filter is upon your element now and forever.

(IE 6 doesn’t have this behavior, oddly enough.)

Nobody seemed to have solved this problem as far as I could see — scriptaculous’s home page displays this problem, for instance. This meant I had to do without fades on Gimcrack’d, since all you do on the site is read text. Then I realized there was a way around the problem.

Show me the better way

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nunc sit amet felis. Sed purus diam, euismod accumsan, suscipit non, volutpat ut, urna. Pellentesque tellus. Maecenas in lacus. Fusce sem nisl, laoreet vitae, laoreet sed, lobortis sit amet, nisl. Mauris tincidunt semper nisi. Sed in lorem eu nulla condimentum dignissim. Vestibulum convallis justo et quam. Sed enim. Nam eget ipsum eu mi facilisis interdum. Etiam eros elit, vestibulum quis, pellentesque vitae, auctor ac, purus.

The trick is that right before the transition occurs, we create a copy of the element, then swap it in for the original. When the fade is done, we swap back in the original, still safely anti-aliased, and delete the copy. This looks a little odd during the transition since it is briefly ugly during the fade… but that’s an acceptable tradeoff to me. The important thing is that it looks good afterwards.

The only other problem is that the native method cloneNode used to create a copy doesn’t copy over event handlers, only the elements themselves. That’s ok by me, too. I think it’s pretty unlikely that anyone is going to try to interact with an element while it’s fading in, and besides, if it’s that much of an issue, there are better ways to copy DOM elements out there — Mootools has one, at least, and I’m sure other frameworks do too.

Check out the code. It is purposefully framework agnostic — mainly because I don’t use any frameworks on Gimcrack’d.

— Chris, 9 September 2007

18 comments

Write a comment