Improve this Doc

# Internet Explorer Compatibility

Note: AngularJS 1.3 has dropped support for IE8. Read more about it on our blog. AngularJS 1.2 will continue to support IE8, but the core team does not plan to spend time addressing issues specific to IE8 or earlier.

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.