Internet Explorer Compatibility

This document describes the Internet Explorer (IE) idiosyncrasies when dealing with custom HTML attributes and tags. Read this document if you are planning on deploying your AngularJS application on IE.

The project currently supports and will attempt to fix bugs for IE9 and above. The continuous integration server runs all unit tests against IE9, IE10, and IE11. See CircleCI.

We do not run tests on IE8 and below. A subset of the AngularJS functionality may work on these browsers, but it is up to you to test and decide whether it works for your particular app.

To ensure your AngularJS application works on IE please consider:

1. Use ng-style tags instead of style="{{ someCss }}". The latter works in Chrome, Firefox, Safari and Edge but does not work in Internet Explorer (even 11).
2. For the type attribute of buttons, use ng-attr-type tags instead of type="{{ someExpression }}". If using the latter, Internet Explorer overwrites the expression with type="submit" before AngularJS has a chance to interpolate it.
3. For the value attribute of progress, use ng-attr-value tags instead of value="{{ someExpression}}". If using the latter, Internet Explorer overwrites the expression with value="0" before AngularJS has a chance to interpolate it.
4. For the placeholder attribute of textarea, use ng-attr-placeholder tags instead of placeholder="{{ someExpression }}". If using the latter, Internet Explorer will error on accessing the nodeValue on a parentless TextNode in Internet Explorer 10 & 11 (see issue 5025).
5. Using the disabled attribute on an element that has descendant form controls can result in unexpected behavior in Internet Explorer 11. For example, the value of descendant input elements with ng-model will not reflect the model (or changes to the model), and the value of the placeholder attribute will be inserted as the input's value. Descendant select elements will also be inoperable, as if they had the disabled attribute applied to them, which may not be the intended effect. To work around this unexpected behavior, 1) avoid using the identifier disabled for custom attribute directives that are on elements with descendant form controls, and 2) avoid using disabled as an identifier for an attribute passed to a custom directive that has descendant form controls.