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.

Again, I congratulate the browser teams who have passed the Acid3 and have only one more thing to say:

Don't ever do that again.

I'm right in the middle of going through the proofs for Painting the Web, and I'm having to make proof modifications to code and writing because both Safari and Opera are feverishly changing their source in order to "meet" the Acid3 test. However, I don't know, for sure, if all the changes will end up in the next released version of the browsers, or if they'll be shunted off as a branch for inclusion in a later browser version after further refinement.

A better approach would be to list out all of the Acid3 tests and create a roadmap of planned implementation, ie the functionality in test 1 will be included in Opera 9.5, the functionality in test 2 in Safari 4.0, and so on. It may lack the glamour of displaying a passed test results, but it plays less havoc on those writing documentation, testers, book writers, and other people who have ended up being tossed about, like so much flotsam, by the Acid3 hurricane, and are now feeling particularly bruised and battered.

Please don't do an Acid4. I don't know if I can survive it.

I'm in the process of proofing Painting the Web, including testing all of the examples with the new IE8 beta. Yeah, fools rush in where angels fear to tread.

I was frustrated that all of my canvas examples weren't working with IE8, even if I picked IE7 emulation mode. From a Google group I discovered that if I used quirks mode (ie, removed the DOCTYPE), the applications do work in IE8 and in IE7 mode, both. (Well, some of the applications–but at least I see some of the pieces with the ones that don't work.)

I tried the meta tag and using IE7 strict mode, but it doesn't work, though it doesn't break as badly as IE8 standards mode. You see a box where the canvas rendering should be.

So, what this demonstrates is that Microsoft is dropping support for VML, but hasn't implemented the HTML5 canvas element. More importantly, Microsoft doesn't support VML in strict mode even if you're running in IE7 mode. Jay-sus Microsoft, could you possibly leave things in worse shape?

However, further checking finds for us a Silverlight version of excanvas.js. Well, we knew that one was coming. Still, the problems with using Silverlight is that your page readers have to install Silverlight. Previously, all of the effort to translate canvas to Microsoft speak occurred without the reader having to install anything. This is a better approach that we no longer have. In addition, I don't believe that Silverlight works with IE6, though I don't know for sure, since I don't have IE6 to test.

More importantly, this new JavaScript library works in IE7 emulation mode, but is pretty buggy in IE8 standards mode, though at least it works in Strict not Quirks. And, as long as you name the JavaScript files differently, you can include both JS libraries, which should enable the canvas applications to work with IE6. I don't have access to check this out with IE6–I'm just making a guess. Having both libraries doesn't break IE8, whether as IE8 or IE7 emulation. I don't know if having both will break IE7. The real IE7.

Who's on first?

Jay-sus Microsoft.

update MS does still support VML, I tried out a couple of pages that use VML directly and they work. The problem is in the excanvas.js library, then. It should work in IE7 emulation, because the examples did work with IE7. However, it doesn't unless you also serve up the application in quirks mode (with no DOCTYPE).

I tried an SVN snapshot version of excanvas.js, the older one that's still being developed, but it's worse than the released version. However, that doesn't mean that there won't be a release of the non-Silverlight excanvas that will work with IE8 at some point.

Until then, currently:

The released version of excanvas.js only works in quirks mode for IE8, including running IE8 in IE7 emulation mode. Using the new meta tag doesn't work, unless I used it incorrectly. I'm assuming one would use the following:

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

Do I have that wrong?

The Silverlight version of excanvas.js works in IE8 standards, and IE7 strict mode, but it's not released yet, is still under development, and requires your page readers to install Silverlight. In addition, I don't know that this library works with IE6.

I have included both in web pages, and assume one can use IE6 conditional statements to wrap the non-Silverlight option to ensure only IE6 picks it up:

<!--[if IE 6]>
<script type="text/javascript" src="originalexcanvas.js">
</script>
<![endif]-->

I have found, though, that when running IE in IE8 standards mode, most of the sample applications I had partially failed with the Silverlight version of the library. The only reliable results I received with IE8 was using quirks mode with the older excanvas.js library.

last update

Another area impacted by changes associated with VML is the mapping APIs provided by Google and Yahoo (non-Flash version). I've found if you do add the meta tag above, the applications mostly work. Some of the routing is off with Yahoo maps, but it's close enough.