There are few parts of the web developer's job that are more frustrating than getting things to work right in Internet Explorer.
I've read that it's good practice to develop for the most standards compliant browser available, and then tweak as necessary to achieve cross-browser compatibility. Generally, I agree, but once you have a completed web application it can be very difficult to debug in Internet Explorer, since the error messages are usually substantially less than helpful. The error reported is often vague, and in my experience the line number provided is incorrect about half of the time. Some things may be improved in IE7, but it's not yet safe to assume your users will have upgraded.
I've developed several web applications for Firefox that I've then modified to work in Internet Explorer 6. With experience you learn to avoid a lot of potential problems. For example, specifying a doctype will avert many of Internet Explorer's more egregious CSS rendering offenses (more info on that here). More generally, if there are two ways to accomplish something, and both work in Firefox, but only one works in Internet Explorer, you're better off just using the one that works in both right from the start, even if it's less elegant. So a lot of the more famous and obvious problems with Internet Explorer's implementations of JavaScript and CSS don't really affect me anymore, but I still get hit by surprises now and then, when I try to do something obscure and discover an oddly specific failing or difference - sometimes after hours of frustrating debugging. When that happens, I take note of it, so that that particular problem won't catch me off guard again. Here's the current list, so that you can be prepared too.
id attribute. If you try to declare such a variable without the "var" keyword first (such as if you are declaring a global variable within a function) Internet Explorer will assume you are referring to the element with the corresponding id, as if your code were document.getElementById('variable_name');. Chances are this will immediately lead to an "Object does not support that property or method" error and the death of your script.character = string[index];. However, this will not work in Internet Explorer. Instead you will have to use the charAt method, like so: character = string.charAt(index);.delete is JavaScript's way to undefine a variable (see the Mozilla reference page for more information). But it has certain limitations. For example, in my first foray into JavaScript's version of class definitions, I wrote a destroy() method that ended with delete this;. Firefox allowed it; Internet Explorer did not. ) in the cell..triangle
{
border-left:8px solid transparent;
border-right:8px solid transparent;
}
*html .triangle
{
border-right-color:#FFFFFF;
border-left-color:#FFFFFF;
}position attribute in Internet Explorer. One that snuck up on me one day is that position:relative; on an element with a parent with a specified overflow attribute is interpreted instead as position:fixed; - the best way to work around this problem will depend completely the specific layout in which it appears. In my case I rearranged the DOM tree slightly such that the relatively positioned elements no longer had such a parent.<input type="submit">) seem to have large values for left-padding and right-padding, despite CSS declarations to the contrary. It's probably better to use a more-flexible <a> instead, with onclick=JavaScript:TheForm.submit();.element:hover) on elements other than <a>. (In particular I have seen it fail for <tr>, <td>, and <div>.) To achieve the same effect, mouseover and mouseout event handlers have to be attached to the element and change its style.<select> elements, ignore z-index in Internet Explorer, and thus will "bleed through" anything placed on top of them. To actually cover them, they have to either be moved or have their style changed to include display:hidden; - which may affect the dimensions or line-height of their containers, depending on the specific layout.overflow:hidden; declarations, I've also had an extremely bizarre problem that was solved by the removal of that declaration. I had a page that contained, among other things, an iframe holding a Java applet. (This was a solution to the cross-browser problem that Java applets are extremely finicky and difficult to cover up - they ignore z-index and don't respond well to being moved or hidden. But it is possible to put them in an iframe and move the iframe outside of the visible boundaries of its container (with overflow:hidden; on the container) to hide it, and move the iframe back to show it again.) While the iframe had overflow:hidden;, machines outside of our internal network (despite the fact that the page was hosted outside of the firewall) running Internet Explorer would fail to display the applet, although they would load and execute it otherwise perfectly.<body onMouseDown="captureMouseDown(event);" onMouseUp="captureMouseUp(event);" onMouseMove="captureMouseMove(event);" onContextMenu="return contextShow(event);">. The odd thing is that attaching the event handlers in JavaScript did not generate any errors or halt script execution - it just silently failed.innerHTML for the presence of a certain tag, or checking an element's tagName property, you should likely do so in a case-insensitive fashion. Internet Explorer uppercases the names of certain tags - for instance, <img> in your actual source code will become <IMG> in the browser.element.setAttribute and element.removeAttribute method calls that attempt to set class, style, or onclick will fail in Internet Explorer. The properties will have to be modified directly with element.className, element.style.(whatever), and element.onclick = function respectively.<table> elements should have a <tbody> element holding their content. Adding rows to a <table> via document.createElement and element.appendChild will cause the table to spontaneously grow a <tbody> - however, any children appended to the <table> element will still append directly to the <table> element. Thus the rows will be inserted outside of the <tbody> and will not be displayed.createElement and appendChild with innerHTML assignment when it comes to <tbody> elements. After appendChilding a <tbody> to a <table>, trying to set the <tbody>'s innerHTML property causes an "Unknown Runtime Error."createElement and appendChild lends itself to has to due with the garbage collector's poor reference counter - if script-bearing elements are not attached in a top-down fashion, memory leaks will build until the browser crashes. I found this out the hard way when building a large table with onclick events on the cells using createElement and appendChild before appending the table itself to the document.<li> elements have a value attribute. In an ordered list, it lets you specify the number that should precede this list item - so you can have an ordered list of items numbered 4, 53, 243, and 8764 if you want. According to W3Schools, it is deprecated and styles should be used instead. But I've looked fairly extensively and have found no way whatsoever to achieve this effect in styles, short of abandoning <li> elements altogether and faking the list with some <div> or <span> elements or somesuch, in which case you lose semantic value. So, should you find yourself needing to dynamically create an arbitrarily-numbered list, you should know that attempting to set the value attribute of an <li> element, either by element.value=x; or element.setAttribute('value',x);, will cause Internet Explorer to halt script execution without generating an error. (Consequently, the failure can take some time to track down.) Thus the list must be generated using innerHTML - but after the previous few issues as well as the fact that innerHTML is faster, you really should just be using innerHTML everywhere you can.