JavaScript support in Browsers

Opacity returns to IE8

Shelley Fri, 09/12/2008 - 19:03

When IE8 beta 1 released, there was a minor uproar at the fact that Microsoft had dropped support for its proprietary version of opacity, while not providing support for the newer CSS-based opacity.

Gone were the days when the following CSS setting would change the opacity of an element in all of the major browsers:

#somediv 
{
  opacity: 0.0; filter: alpha(opacity=0);
}

If you wanted to get opacity to work with IE8, either you'd have to have your users turn on the IE7 compatibility mode, or you'd have to add a meta tag to your web page:

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

Yesterday, Microsoft released a post on the IEBlog that had both good and bad news. The good news was that opacity was back. The bad news was that setting opacity in such a way that IE8 would process it as IE8 is now more complicated than ever.

It seems that the reason Microsoft pulled the old filter syntax is because the format was not CSS 2.1 compatible. However, according to comments in the post, Microsoft couldn't just transfer the opacity functionality over to the CSS approach, because the behavior between the two, CSS and Microsoft filter behavior, differs.

Due to the gently incessant requests (!?) of web developers, Microsoft has added back in the opacity filter. However, the company is using the naming convention standardized for browser based CSS extensions, which means it still meets the CSS 2.1 requirements. Where the old, formalized, filter setting looked like the following:

filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=0)

Which had illegal characters, including the equal sign, Microsoft now has the following:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";

Notice the use of the "-ms-" prefix on the filter, and the use of quotes to enclose the setting, and hide the illegal characters.

Of course, for the opacity setting to work with both IE7 and IE8, we have to use both. According to Microsoft, we have to list the new extension format first, and then older setting. This in addition to the CSS opacity setting:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";
filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=0);
opacity: 0;

I created a simple example to demonstrate how opacity would work, honoring both formats. It includes setting opacity with JavaScript, and works with Firefox, Safari, Opera, IE8, and as tested with IE7 compatibility mode. Click the image several times to hide one image, and expose another.

theobj.style.filter='progid:DXImageTransform.Microsoft.Alpha(Opacity=' + opacity + ')';
theobj.style.opacity=value;

The challenge isn't over yet, though. The images in the first test are JPEGs, but I also tried the example with PNGs with alpha transparency. Unfortunately, IE8 beta 2 supports opacity, but if opacity settings are applied to an image or element containing an image, and the image is a PNG that incorporates alpha transparency, the transparent effect is lost when the opacity is changed.

In older versions of IE, PNG alpha transparency was set with the AlphaImageLoader, like the following:

#div1 img {
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src=fig0902.png,
sizingMethod='scale');
}

In IE8, which normally would support the PNG transparency, when the opacity filter is changed, the alpha transparency is lost. To compensate, when the containing element's opacity is changed, the image's alpha transparency also has to be set in script, as demonstrated in a second example:

document.getElementById("img1").style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src=fig0902.png,sizingMethod='scale')";

Since the alpha transparency in PNGs is supported with IE8 (and IE7), the CSS setting doesn't seem to need the new Microsoft extension naming. However, unless the image's alpha transparency setting is "reset" after changing the opacity, the transparency is lost when the application is run as IE8, as you can see from a third example. Oddly enough, the problem with the alpha transparency on the PNGs doesn't happen in IE7 compatibility mode. The only thing I can think is more than the name has changed with IE8's opacity implementation.

Of course, if you use the EmulateIE7 meta tag, you don't have to muck around with the new opacity extension, or resetting the PNG filter, but you also don't get the other CSS 2.1 standard settings from IE8.

IE8 beta 2: First Experiences

Shelley Sun, 08/31/2008 - 09:36

My first experiences with IE8 beta 2 have been mixed. On the one hand, I like the fact that compatibility mode no longer requires restarting the browser. However, I've found it virtually impossible to tell when I have compatibility mode turned on or off. I've also found that once turned on, you do have to reload a page in order to turn it off again, because the button disappears.

Sam Ruby wrote about an improved namespace blurb that appeared about IE8 at a Microsoft site, which has since disappeared. In the post, Sam also mentioned that IE8 no longer supports CSS for elements it doesn't recognize, also detailed in a bug Anne van Kesteren linked in comments.

I went to check out the bug at Microsoft's LiveConnect with IE8 beta 2, but received an error in the page that I don't have permission to view the page. Puzzled, I also noticed that the page asked if I wanted to sign out of LiveConnect.

I had originally obtained a LiveConnect login in order to report bugs about Expression Media, which I was testing for my Painting the Web book. I figured that somehow my old account was interacting with the page in such a way as to make it inaccessible. I tried to delete cookies, in fact every kind of storage associated with IE8, but I still received the same page: I don't have permission to access the bug, would I like to sign out of LiveConnect.

I looked more closely at the IE8 Delete options, and noticed that there's another option I missed, Preserve favorite website data, with the following explanation:

Keep cookies and temporary files that enable your favorite websites to retain preferences and display faster.

This checkbox overrides the cookie deletion option when login information is stored. *I'm not sure if this option was present with IE8 beta 1, and I'm not sure I like it—one could easily think they've cleared all personal information out of a browser by deleting cookies, only to forget to uncheck the favorite site option, and leave critical logins still active.

Hakon Lie wrote about Microsoft's back stepping on standards mode. Microsoft had originally stated it would support standards mode by default with the first beta of IE8. Now, it supports standards mode by default on the internet, but supports the old IE7 non-standards mode by default for intranet accesses. The setting can be changed via a menu option, but the problem with this approach is that if you develop a web site internally and it works one way, it may break or work oddly once published externally, unless you remember to turn standards mode on when developing the page internally. This adds all new meaning to the term, quirks mode, as this really is quirky behavior.

IE8 does implement the new JSON object, though be forewarned: it treats single quotes as second class citizens. In other words if your application returns strings delimited with single quotes, your application will fail. The JSON with single quotes still works with eval, though, so you could end up with breaking behavior when you switch from one to the other. To be honest, I find this to be a flaw with the JSON "standard"—either JSON is JavaScript Object Notation, or it's not, and single quotes can delimit strings in JavaScript.

One new feature, or at least another feature I don't remember from IE8 beta 1 is that when you encounter a runtime error in JavaScript, IE8 now pops up a window with a note about a runtime error, and asks if you wish to debug it. I imagine this will only appear if you have developer tools enabled. The script debugger included with IE8 in beta 1 is still available in beta 2, and is one really nice feature in IE8.

Less nice, though, is Microsoft's non-support for DOM Level 2 event handling. There's also no need to go into details about how the browser doesn't support XHTML and SVG and MathML—Microsoft will never support XHTML, which should be a disappointing given now. In fact, it's unlikely Microsoft will ever support SVG, even if this gets included in HTML5. Some would say this will kill SVG. I disagree and believe that this will eventually kill IE. Not just the lack of SVG support: Microsoft's refusal to deal effectively with the issue of XHTML support, DOM Level 2 event handling support, and so on. Too many gaping holes in standards support, and too little commitment on Microsoft's part to truly be a standards-based browser.

On the other hand, IE8 does have improved support for CSS. It's now about equivalent to Firefox 2 in CSS support.

Lastly, if you're a Netflix Watch Now fan, be warned: IE8 beta 2 does not work with the Watch Now feature, no matter what mode you set. Do not install IE8 beta 2 if you use this feature.

All in all, beta 2 has the feel of being a rushed delivery. Not surprising when you consider beta 2 was released on the seventh anniversary of the release of IE6—a day some of us designated as IE6 EOL or Uninstall day.


*The Preserve favorite option is new with beta 2, but is not working as described. It's preserving data for sites that are not on my favorites list. In addition, Microsoft puts its own sites on this list, automatically making data to them "saved" with this option.

You Can Stuff Your Bug

Shelley Wed, 07/30/2008 - 16:06

In reply to the IEBlog web post that is asking people to apply for the right to submit a bug:

Why, on earth, when other browser developers provide open and easy to use bug systems, would Microsoft limit itself in this way?

I have a bug in Webkit, five minutes can help me determine if someone had already reported the bug; no more than another five to submit the bug, with test case.

Mozilla created software to make it easy to search on, and submit bugs. Why, I bet even you all could use it.

Opera has a handy, dandy bug form that makes bug submission a snap.

And here is the IE team "If you email us and ask us really nice we may, just may, mind you, deign to let you actually tell us about that bug, which if left in the released product will haunt us until the end of time. If you don't ask nice, you can stuff your bug."

We Can't Afford Another Browser War

Shelley Wed, 10/31/2007 - 19:00

It was with a sense of foreboding that I read the posts that swam past on Planet Intertwingly today. First came Mozilla's Brendan Eich's chastisement of Microsoft's Chris Wilson, followed in a short while by commentary by Sam Ruby, where he wrote:

It is interesting how the don’t-break-the-web meme means different things to different organizations: Mozilla, Microsoft.

I'm not a language designer. My only stipulation with a new scripting language is that whatever constructs are added to ECMAScript4 need to be backward compatible. We can't afford to re-write a couple of billion web pages because the ECMAScript group got clever. From what I've read in the past and in these new writings, Eich concurs, as does several other members of the team.

In regards to the new items added to the language: I share other concerns that ECMAScript–no let's call it JavaScript because that's how it's known in the world–may become bloated and over large. I can understand about making it into a 'real' language, but I'm less concerned with posterity than I am getting a job done, quickly and efficiently. In other words: I don't have any ego involved with the fact that I work with a programming language many folks consider somehow less worthy. If the extensions make a better language enabling me to do a better job, that's great. Otherwise, leave the esoteric for ACM papers.

The future perfect ECMAScript is currently not my concern. My concern on this interchange between Mozilla's Eich and Microsoft's Wilson is that we're seeing the seeds being planted for another round of browser wars, similar to what we had a decade ago. However, today's web isn't like the web of a decade ago, because today's web pages are much too complex to attempt to cover every nuance and difference in implementation with if statements and conditional tests. It was especially disquieting to read comments to the effect that, it's OK if the companies don't agree: we can use Flash. Flash is not an alternative to open standards. We don't need any more Flash dependency as a way of 'soothing over' corporate intransigence. Neither do we need more SVG plug-ins, or Google cross-browser libraries. Workarounds are no longer acceptable.

Any company is going to want to implement a version of any specification that favors what they currently have, as much as possible. Of course, this is understandable. Accept the fact that this is understandable. What keeps this behavior in line is there is enough push from other forces that everyone eventually has to compromise, and no one is a clear winner. When no organization is a clear winner, this typically means that everyone, eventually, ends up being a winner.

There's no denying that Internet Explorer continues to be a problem. I found it unacceptable that Microsoft would put in time to create its own 2D graphics system with Silverlight, when one already exists with both SVG and Canvas (the Canvas object, not markup element). There was absolutely no good reason for this, and no amount of plushy blue monster or outreach effort is going to hide the fact that Microsoft basically did it's own selfish thing with Silverlight.

There is no denying, however, that Microsoft's browser continues to dominate (though every year, it dominates less). There is also no denying that Eich has considerable ego invested in ECMAScript–to the point where I have to wonder if this may make him overly aggressive, leading to confrontations that could injure the likelihood of pulling together a new version of JavaScript all browser makers are willing to endorse. We need a consistent platform: no matter how good the language, if a sizable number of people are using a browser that doesn't implement it, the language is screwed, the browsers are screwed, we're screwed.

"So I'll expect to see no more of these lies spread by you." No matter how angry you get, or frustrated, or peeved, if you want to work in an open standards group, particularly if you want to lead an open standards effect, you can't write statements like this! Period. End of story. Along with the authority of leadership comes responsibility, and such statements are irresponsible. Where is Mitchell Baker? Time for her to step in and exert a calming influence. At a minimum, act as referee.

The same could be said for the Microsoft representation. No matter how subtly worded, we're picking up our marbles and going home, neener, neener is not 'working together as a team'; nor is it considering the true best interests of the web, in general, and of those loyal to Microsoft products, specifically.

Sam mentions that this issue is one based on culture. Frankly, from these exchanges, it seems more like a pissing contest to me.

Disappointing.