Web browsers differences

Internet Explorer

General

• Usually if you get an "Expected identifier, string or number" error, this means you have an extra "," at the end of a class or JS object. The best way is to comment out the injected JS files until you find out which one has the problem.
• Only use Prototype JS code or you'll run into troubles (mainly because all elements should be extended Prototype elements to ensure cross-browser behavior).
• IE caches *a lot*. In particular Ajax requests can be cached! Be sure to put some caching directives on the server side, else IE simply won't hit your server again. It'll use the cached version.

Developer tools

• Debugging JavaScript on IE is a lot harder than on FF. For debugging JavaScript, the best way is to install Visual Studio Express Web 2008 and follow these instructions (IE has to be the default browser).
• To get something similar to Firebug, install the Internet Explorer Developer toolbar.

CSS bugs

• IE 7 has a bug regarding elements with z-index (absolutely positioned elements with relatively positioned parents). Basically if you have an relatively positioned element, it starts a new stacking context and thus its child will have their z-index based on this context... not the real context which is usually the body. Good explanation.
• IE does not properly support CSS comments; multiple CSS comments on one line, with an actual property / value set, confuses the poor piece of crap.
• IE seems to have a bug when multiple floated divs are present on a container, with their widths in percentage. If the percentage amounts to exactly one hundred (100%), then it will not render correctly. To fix this, you can just make the widths go only to 99% if possible.
• IE does not like absolute positioning on anchor elements or images; but you can usually fix it by wrapping in a div or span. Apparently for IE it is better to give both top and left properties for absolutely positioned elements (eg, both coordinates).
• text-align: center can also cause misbehavior, usually you can fix it by only applying this property to a subelement.
• IE 7 does not support attribute selector when the attribute is "for" (on a label).
• IE 7 has a strange behavior on an absolutely positioned element when top: is used (bottom is fine) and the relatively positioned ancestor has not a width of auto. Having a 100% width confuses IE. It is important with our technique for a generic skinning of a block for example (when the block did not have a fixed width this caused problems).
• If you have new lines in anchor (<a>) elements, IE may mess your page (the behavior I got was that IE thought the page was very wide, so I got an horizontal scrollbar).
• Relatively positioned elements on a div with overflow (when there is a scrollbar) don't behave properly. The solution is to add "position: relative;" to the container div (the one with overflow).
• IE cannot apply display: inline-block to a div without a hack (setting display: inline for this div in a second rule, after the first rule specifying the display: inline-block). For inline elements this works fine.
• Margins on inline-replaced elements (like images) behave poorly, as the text is not placed correctly vertically. You can add a vertical-aling property to the container to try to fix this, but generally speaking, vertical margins for inline-replaced elements are dangerous.
• Horizontal margins on a relatively positioned element descendant of a float can produce problems.

JavaScript bugs

• The "change" event does not work as expected on checkboxes (it fires only when the checkbox loses focus). A workaround is to use the "click" event.
• Same thing for radio buttons.
• When adding a CSS rule dynamically to a stylesheet, IE chokes if the rule selector part actually contains more than one selector. Eg, if the selector contains the "," syntax element. You must manually break the rule into two rules before.
• Also note that when dealing with stylesheets dynamically, IE seems to be at least 20 times slower than Firefox.
• IE cannot update the contents of an inline CSS stylesheet with Prototype update() (or innerHTML). The changes won't be displayed instantly on the page. You must use the CSS stylesheet APIs to do this.
• The results of a regular expression evaluation in IE may be empty strings, whereas in Firefox it's undefined (null) objects.
• IE forbids the use of appendChild(), update() - or innerHTML - on a style element. A workaround:

newElement = new Element("style", {"type": "text/css", "id": id});
newElement.styleSheet.cssText = data;

• Another workaround, with more code (but potentially works better):

while (true)
{
	try
	{
		inlineStyleSheetElement.styleSheet.removeRule();
	}
	catch (e)
	{
		break;
	}
}

data.split("}").reverse().each(function(rule)
{
	if (-1 != rule.indexOf("{"))
	{
		rule = rule + "\n}";
		ruleSelectorPart = rule.substr(0, rule.indexOf("{"));
		ruleSelectors = ruleSelectorPart.split(",");

		
		ruleSelectors.each(function (ruleSelector)
		{
			inlineStyleSheetElement.styleSheet.addRule(ruleSelector, rule.substr(rule.indexOf("{")));
		});	
	}
});

• IE does not fire the "load" event for script elements. The only way to know when IE has finished loading the script is to call a callback function at the end of the script file.

• The "keypress" event does not work for detecting tab key presses. "keydown" works fine.

• removeAttribute() does not work on IE, so use Prototype's writeAttribute(attr, false).

Different behavior than Firefox (not necessarily bugs)

• IE 7 automatically adds margins to forms. You can override that behavior with CSS.

Links

• A good link to IE 7 bugs.

Opera

• location.hash is bugged when the hash contains a question mark. Update: this seems to have been fixed.
• myForm.readAttribute("action") behaves differently in Opera, as it adds the hostname before (which is bad!). The bug was apparently fixed in Opera 9.50 (see this bug reference).
• Opera automatically adds margins to forms.
• Opera does not fire the "load" event on an newly created image, which has already been downloaded (eg, whose source corresponds to an already fetched element). This is probably a bug that hopefully will be fixed.

CSS

• When using an element with fixed position at the bottom of the page, you usually add an absolutely positioned element with a negative bottom value to provide scrolling. This technique does not seem to work very well in Opera.

JavaScript

• Opera has a default behavior when using a mousedown event on an image. You can prevent that from happening with event.stop() in Prototype as usual. However, if in the same function you move an image directly under the mouse (for example this could be the case with a slider...), another mousedown event launches, this time on the moved image! And then you get the annoying behavior. This can easily be fixed by stopping the second event. I consider this a bug as Firefox does not launch the second event. Once the original event is stopped, nothing further happens.

WebKit

Safari

• Safari has a development / debug mode, but it does not seem to work well under Windows.

Chrome

• Chrome has a very nice inspector / console panel, although with some bugs (no docking, refreshing is strange).

JavaScript

• Safari does not allow the contents of a XHTML style element to be updated. A workaround is to remove the element, and add a new style element.

Firefox

CSS

• You cannot correctly change the properties of a file upload form field with CSS. Firefox has a bug that prevents width from correctly working on the associated text field. All other browsers support this correctly though.

JavaScript

• Firefox 3 has a bug that prevents the use of the stylesheet DOM APIs on an external stylesheet, eg a stylesheet hosted on an external host. The workaround is to use an inline stylesheet.

Firebug Lite

• The current 1.2.1 version of Firebug Lite is broken (loads all the time when opened, even on Firefox). The best way to currently use Firebug Lite is to load it via a bookmarklet.