Bb's RealTech

Another break between IE7 and IE8 is the support for opacity.

In previous versions of Internet Explorer, Microsoft used its own custom filters in order to implement opacity. This has been known for some time and libraries manage opacity for old and new browsers by using code like the following, in JavaScript:

// cross-browser adjust opacity function
function setOpacity(obj,val) {
  obj.style.opacity = val;
  obj.style.MozOpacity=val;
  obj.style.KhtmlOpacity=val;
  val*=100;
  obj.style.filter = "alpha(opacity="+val+")";
}

It's a trick that takes advantage of JavaScript's dynamic prototyping to "set" any possible combination of opacity properties, including the CSS3 opacity, the older Mozilla opacity, as well as IE's opacity filter. Of course now, we can pretty much drop anything but the CSS3 opacity, and the IE filter:

// cross-browser adjust opacity function
function setOpacity(obj,val) {
  obj.style.opacity = val;
  val*=100;
  obj.style.filter = "alpha(opacity="+val+")";
}

This will work with IE6 and IE7, but not IE8. The reason why is that Microsoft dropped implementation of a proprietary functionality called hasLayout, which the company's opacity filter was dependent on (at least, that's what I've read). This is good, because hasLayout is a Bad Thing.

Unfortunately, this also "broke the web" in that Microsoft, in IE8 beta 1 at least, didn't bother to replace the now missing opacity filter with support for the CSS3 opacity filter. True, CSS3 isn't a "released spec" yet, but every other browser–Firefox, Safari, and Opera–supports CSS3 opacity.

I've explored the online discussions related to IE8 and opacity, and there are rumors that the long handled Alpha opacity filter will work, but I've not found that this to be true, and I've not found anything at Microsoft on a workaround.

At this time, and to the best of my knowledge, to get opacity to work with IE8, you'll have to add the IE compatibility meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

You put this meta element right after the title element. Of course, you lose the "good" standards stuff that comes with IE8 if you do this. It's a damned if you do, damned if you don't situation: either opacity doesn't work with IE8, or you lose the stuff that does work correctly with IE8.

I'm also finding another problem with IE8: adding an onclick event handler to a DIV element seems to only be sensitized to whatever content is in that element, not the element itself. So if you have centered text in the DIV element, only the text is sensitized to the onclick event, not the entire block.

This impacts on many Ajax applications, including most accordion functionality, and not just on mine. For instance, Rico's Accordion widget doesn't work with IE8 if the person clicks anywhere but the text. To recapture this functionality, you'll again have to use the compatibility meta tag.

Though RealTech is a weblog, it's also the place where I do much of my experimentation with technology. It's the site I use to test out the plug-ins, graphics applications, and what not I'm eventually planning on using in the rest of my web sites. Normally you don't use a 'live' site to test changes, but I happen to think a live technology weblog is one of the better places to try something out. All those juicy testers.

However, one of the downsides to such effort is that the page may be challenging to access at times. Or a challenge to access at all times for IE7 and lower if it comes to that.

Another downside is that when I'm pushing one type of technology, my uses of other technologies may make it seem like the one I'm pushing is causing problems, when the reality is it could be any number of other tweaks and tricks.

As an example, I'm a big fan of SVG and XHTML. I serve my pages up as XHTML, and I use SVG inline. I write quite a bit on XHTML and SVG because I'm trying to encourage the use of both. If you access this page and it loads slowly, or seems to have other problems, you might think ithe problems are generated by my use of SVG, because it's the technology I write about the most. However, it could also just as likely be any of a number of other tweaks I'm currently trying out.

In my post Wordpress at the Top: Not, a couple of folks (Seth and Daniel) mentioned they had problems loading the page and scrolling and both thought it might be the inline SVG. It's true that in their client environments, the inline SVG could be causing the problems–especially with my use of gradients, which are quite CPU intensive.

However, a little experimentation of my own shows that problems with the scrolling could also be caused by two older technologies: the first being the use of the CSS fixed background, which no browser seems to handle efficiently; the second being the use of the JavaScript-collapsed posts.

I also use rather large images in the header, and load them as background for elements, which turns off image caching. The lack of caching and the larger image sizes, combined with the derived CSS could slow load times. However, my experiments for sampling images and deriving CSS elements rather depends on my use of the CSS background attributes for adding the images, rather than just loading them using IMG.

To determine whether it is the SVG causing problems, or my other tweaks, I've removed the fixed CSS positioning, for now, as well as the collapsed posts and optimized the images and slimmed down the code deriving the CSS. If you've noticed performance problems in the past, can you access the pages now and see if the problems you had have been eliminated?

In the meantime, in addition to the other changes I'm making to support XHTML (BTW, you'll notice that my XHTML validation of comments is too strict at this time, and will more or less give you invalid errors for any use of element attributes), I'm going to look more closely at my use of photo sampling, photo as CSS background, and what I can do to improve this type of functionality.

Then I'll probably corrupt all that hard work by experimenting around with something else new, and causing my site performance to tank. Again.

These are my links for January 14th:

• Trolls, Communication, and the Wild, Wild Web. | BlogHer - "I'll never rush onto The Troll Train again."
• Thoughts on Firefox 3.0 - O'Reilly XML Blog - In-Depth look at Firefox 3.0. Some changes implement released specs, some are for specs under development. Choose wisely, grasshopper.
• G - L - O - R - I - A - "The difference, in thirty years… is that I may speak freely about this asshole and many others." Zo points to a Gloria ('the' Gloria) article.
• With friends like these … Tom Hodgkinson on the politics of the people behind Facebook | Technology | The Guardian - Excellent write-up on the philosophies of the executive board of Facebook. Should be enough to knock the warm and fuzzies out of the fans.