Internet Explorer still has some problems with jQuery animations and image transparency. When you animate an image by changing its opacity from transparent to opaque, IE shows a black outline that gradually disappears when the animation is complete. This problem affects all jQuery animations and effects, regardless of the image type. To fix this problem, you can write the following code:
Internet Explorer has some problems with handling JavaScript reserved keywords when these appear within a jQuery method. For example, suppose that you want to set a CSS class using the attr() method, like so:
Internet Explorer 6 doesn't support the abbr element. Simply put, IE 6 doesn't recognize this element as a node of the DOM tree. To make IE 6 support this element or, more precisely, to mimic the support to this element, we have to manually create it within the DOM structure. This can be done at the very beginning of our page, like so:
After viewing this example in Internet Explorer 7, I got a surprise: the sub-menu was shown to the right of the active item, not to the left. Internet Explorer 8, instead, shows the sub-menu correctly. In this example I use contextual positioning to dynamically show the sub-menu when the mouse hovers the active item. The active item has the declaration position: relative and the sub-menu is absolutely positioned relatively to it. So what was the problem?
If you take some time to make a little tour through my examples with some versions of Internet Explorer, you will probably notice that when it comes to deal with effects and animations our browser of choice runs into troubles. Basically, IE has a very limited support to jQuery animations, especially to sequential and complex animations. In other words, IE supports only atomic and simple animations and effects, but its support to complex animations is not guaranteed. I've summarized the results of some tests on IE in the following table. Tests have been run using versions 6, 7 and 8 of IE.
jQuery tries to support Internet Explorer, but sometimes this support is not able to prevent IE from returning JavaScript errors, thus blocking the execution of your jQuery code on the page. For example, the demo presented in this post doesn't work in IE. Simply put, IE raises an error during a call to the jQuery UI library. In this post, I'm going to show you the most effective technique to deal with this situation.
Debugging CSS in Internet Explorer 6 and 7 requires the use of some repeated patterns that you've surely encountered or used during the development of a web site. The aim of this post is to provide a simple reference for the most common patterns used with Internet Explorer (also called hacks).
Internet Explorer (6, 7, 8) has a major anomaly with new lines handling in the innerHTML property. This problem was first reported back in 2004, and apparently seems to still affect even the latest versions of IE. On this blog post, the problem is described with these words:
There have always been a lot of complaints from web developers about the current support of Internet Explorer 6 to the jQuery library (see this useful article for example). However, the standpoint of web developers is actually wrong, because they don't take into account the fact that browser implementors don't test jQuery (or any other JavaScript framework) when they build a new release of a web browser. jQuery works not because browsers support it but because jQuery's developers support a given browser and try to make jQuery work in such browser. In other words, jQuery works fine when the core implementation of JavaScript and the DOM is free of bugs or errors. Conversely, when a browser has some bugs in its implementation, these bugs will affect jQuery. This is the case of IE 6.
Microsoft announced the final release of Internet Explorer 9 yesterday, so I think it's time to explain why I don't support older versions of IE (mainly 7 and 6). The reason is simple: supporting older versions of IE is harmful for IE's users. Why? There are two reasons behind this. First, if you support these browsers, you're actually encouraging their users to continue with their bad habits and this is harmful for their computer security. Using an obsolete browser exposes users to malicious attacks that can compromise the integrity of their data. So if you build a web site that fully works in IE 6 and 7, you're indirectly contributing to the massive widespread of malware infections, phishing hoaxes and similar security problems. An obsolete browser is affected by several bugs that may harm a user's computer. Every site that still supports these browsers convinces IE's users that there is no need to upgrade their browsers. If you do that, be aware of the potential danger of what you're doing.
Internet Explorer 6 doesn't support the abbr element, so we're forced to use JavaScript to enable this element in IE 6. Fortunately, jQuery makes this task really easy. All we have to do is to wrap the content of this element with a span element having the same title attribute and a CSS class with some styles attached to it. Since the $.browser() jQuery feature is currently deprecated, we'll use conditional comments to give our code to IE 6. First, a couple of CSS styles:
A client calls you one day. He says he cannot access your web site. So you hurry up to check what's wrong. Everything seems perfectly normal. The problem is that the client is using Internet Explorer 5. Kaboom! So what's next? Internet Explorer 5 has an infamous and poor support to web standards, so even the most simple things get complicated in this browser, not to say impossible to do. The most obvious thing to do is to convince your client to upgrade his browser. Here another problem: he should upgrade his operating system as well. Is there a solution?
Internet Explorer 7 (and lower) doesn't support CSS counters. Fortunately, jQuery is here to help us. The first thing is to set a series of counters and then cycle through the children element of a target element incrementing those counters and adding them to the markup. Given a basic structure like this, with three nested lists:
CSS support in Internet Explorer 6 and 7 is often buggy and incomplete. This turns out to be a real pain in the neck when we want to stylize CSS menus. This post is going to provide some useful rules to make everything work even in these browsers.
Internet Explorer 8 (and lower) doesn't fully support jQuery animations or, more specifically, some values used within the animate() method. For example, the show value is not fully supported when used together with the CSS display and visibility properties. IE will return an error saying that it was not able to get the value for the CSS property in question. Fortunately, there's a workaround. If your goal is to show an element and then animate it, you can still use the show() or fadeIn() methods combined with animate(). An example:
Internet Explorer 6 and, to a less extent, 7, are both affected by some obtuse bugs concerning the styles applied to links. These bugs fall into two categories: block-level bugs and inline bugs. The former category applies to links that are turned into block-level elements, whereas the latter affects inline links. A typical example of the former is when you omit a dimension on links (either width or height). This bug can be easily fixed by adding height: 1px; to the link in question. Another use case if when you have an horizontal menu with floats and you omit to specify the float property for links. In IE 6, this will make links to expand abnormally. To fix this bug, simply do the following:
#navigation a {
float: left;
display: block;
height: 100%;
}
The second category, instead, covers all the CSS styles applied to inline links. The most evident bug of this category is the disappearing of background images on inline links. This bug affects both IE 6 and 7. To fix this bug, you have to follow a two-steps approach:
zoom property to 1:
<head>
<!--[if lte IE 7]>
<style type="text/css">
.inline-fix {zoom: 1;}
</style>
<![endif]-->
</head>
display: inlineAnother bug that I sometimes encountered occurs when you have a breadcrumb menu with a specified height and both IE 6 and 7 crop the text of links because they "think" that the menu is not tall enough. In this case, sometimes omitting the height declaration is helpful.
I was testing a simple navigation
menu created using the HTML5 element nav. Inside this element I put an unordered list with links. Then I tried to attach some styles to it using common CSS
descendant selectors, like this:
nav {
display: block;
}
nav ul {
/* other styles */
}
It worked fine in Firefox, Safari, Opera and Chrome, but not in Internet Explorer 8, where all styles were simply ignored. The reason behind is pretty simple: IE8 not only ignores an unknown HTML5 element, but also prevents this element from being inserted into the normal document tree, thus resulting in cascading leaks when applying CSS. Fortunately, there's a simple fix: just add a class or ID attribute to the normal HTML 4 element that is the parent of the elements you want to stylize, like so:
<nav>
<ul id="navigation">...</ul>
</nav>
Then your CSS styles will work correctly:
nav {display: block;}
#navigation {/* other styles */}
Of course this is a temporary solution, just to allow us to use a standard HTML5 element.
As a matter of fact, for years Internet Explorer has slowed down the global development of web standards and, more broadly, the entire future of the web. For years web developers have been forced to, as Ian Hickson says, code to the lowest common denominator instead of coding to the standards. As a result, now many developers still use a small percentage of the full potential of web standards not because they don't know how to code properly, but because they're afraid of what consequences might result in Internet Explorer.
For example, all JavaScript frameworks devote a significant amount of their inner routines to mitigate the differences between Internet Explorer and the other browsers. Further, the power of CSS3 features is still underused because of the support in Internet Explorer which is still far from getting the level of Firefox, Safari, Chrome, and Opera. What's more, XML and XSLT still rely on the presence of the MSXML library to exploit all their potentialities to the full. Finally, the most advanced features of the latest DOM specifications are still a theoretical thing in Internet Explorer.
How much time we devote to rethink a full website in terms of compatibility with IE? Sure, we're talking about backward compatibility here, the same thing that should make the web look like the old, good '90s, with GIF animations, dial-up modems and no AJAX, no CSS, all tables and, if we are lucky, JavaScript popups. Do you really think your web development process in terms of backward compatibility? I think the majority of developers would all agree to view the web from the forward compatibility point of view. Do you really like the idea of writing a CSS file made up only of class and ID selectors? I guess not.
Do you really enjoy the practice of duplicating your code when you want to use XPath on Internet Explorer? Do you still like all the quirks, bugs, inconsistencies that come along with IE's implementation of web standards? That's quite masochistic, in my opinion. Instead, rethink the web in terms of new features that may be added now, today or in the future. Embrace the future, not the old, sinking relics of a bigon age when the e-mail was the only practical implementation of web communication.
In a nutshell: test in Internet Explorer, if this makes you feel relieved but code just as if IE doesn't exist.
This video shows a detailed comparison between various browsers supporting the CSS3 border-radius property. The point of this video is to demonstrate that with Internet Explorer 9 you have a better support to this property. I'll take the liberty of testing these demos to check out whether what it's been said here is correct.