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

[gscoppino]

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). Changes to the field are not reflected in the model value.
• 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.

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Docs update

What is the current behavior? (You can also link to an open issue here)
Docs do not mention IE11 bug regarding the disabled attribute on elements with descendants (though it shouldn't be used on non-form controls, this issue can prop up when making custom elements/attributes).

A previous issue noticed the incorrect behavior regarding the 'placeholder' attribute on input elements but incorrectly thought the behavior to be a bug with AngularJS:
#15700

I am able to reproduce the issue in the Plunkr created by @Narretz on the aforementioned issue:
http://plnkr.co/edit/jDJv5NtwwDSsp9hRT2rf?p=preview

Also, here's an updated version of the Plunkr showing model value is not updating due to the 'disabled' attribute:
http://plnkr.co/edit/AHix3x3dOzySygDOcfJA?p=preview

What is the new behavior (if this is a feature change)?
Docs mention the bug and suggest preventative measures.

Does this PR introduce a breaking change?
No.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Fix/Feature: Docs have been added/updated
• Fix/Feature: Tests have been added; existing tests pass

Other information:

[Narretz]

Hm, I'm on the fence about this one because while it affects IE it's not very specific to AngularJS and it's also very rare to set disabled attribute on a non-interactive element. Compare that to placeholder which is very likely to get interpolated.

[Narretz]

Hm, I'm on the fence about this one because while it affects IE it's not very specific to AngularJS and it's also very rare to set disabled attribute on a non-interactive element. Compare that to placeholder which is very likely to get interpolated.

[gscoppino]

I'm inclined to agree with you that setting of disabled or using ng-disabled on a non-interactive standard HTML element is out-of-scope, since its unconventional, and it would be rare for it to be used that way, if ever.

However, I think it is within the scope of the document to mention the potential issue of using the name disabled when creating custom tags with attribute parameters or just custom attributes in general, since enhancing existing HTML tags is within the scope of AngularJS and the compatibility page states:

This document describes the Internet Explorer (IE) idiosyncrasies when dealing with custom HTML
attributes and tags.

Perhaps I could modify my doc change to only mention the problem in the context of custom tags/attributes. That way, the information on the IE-specific behavior is tracked and someone with a related issue regarding unconventional use of disabled/ng-disabled in a non-custom element context will also be able to derive where their issue is coming from from looking at the compatibility page.

[Narretz]

Ok, if you stress that this will usually happen in context of custom directives / components, then I'll add it. Please also mention that the workaround is to use a different attribute than 'disabled'.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[Narretz]

Thanks @gscoppino
I've made a few tweaks to the wording - I've removed the part about attribute identifiers from the start, because that's actually a bit confusing, as the problem has nothing to with directives, it just shows up more frequently because of AngularJS' declarative approach.
If you are fine with the changes, I will merge it.

[gscoppino]

I'm fine with the changes. Thanks!