invisi/angular.js
1
0
Fork 0
Code Issues Pull Requests Actions Packages Releases Wiki Activity

docs(guide/Internet Explorer Compatibility): include warnings for usage of 'disabled' attribute

Browse Source 
* docs(guide/Internet Explorer Compatibility): Mention 'disabled' attribute

Setting the 'disabled' attribute on an element that has descendant elements has unexpected behavior in Internet Explorer 11.

* Input elements that are descendants have the text content of the 'placeholder' attribute inserted as the value (and it is not removed when typing in the field).
* Select elements that are descendants are disabled.

To avoid this issue, it is important to not set `disabled` or `ng-disabled` on an element that has descendant form elements. Normally these should only be used on actual form controls so the issue would not manifest.

The issue can also appear if a directive/component is named 'disabled' or takes an attribute named 'disabled' as an input/output attribute, so avoid these.

Closes  #16490
Related #15700
This commit is contained in:
Giuseppe Scoppino
2018-03-19 13:02:52 -04:00
committed by Martin Staffa
parent 980b69dcae
commit 24ddbafbdf
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/content/guide/ie.ngdoc
+9
View File
@@ -39,3 +39,12 @@ To ensure your AngularJS application works on IE please consider:
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](https://github.com/angular/angular.js/issues/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.