No longer setting selected property on <select> elements

[JoshSchreuder]

Request Type: bug

How to reproduce: Create a <select> element. In 1.2.18 this sets the selected attribute correctly, either the first option in the list if the model is clear, or the model value's corresponding <option> element.

In 1.2.19 this does not occur.

Component(s): misc core

Impact: medium

Complexity: small

This issue is related to:

Detailed Description:

Test case here: http://plnkr.co/edit/3zm0K6OK4Dt3DIqZyt06?p=preview

I worked out that the issue exists between 1.2.18 and 1.2.19, specifically this commit: 24aee81

In 1.2.18, Angular sets the selected property on the element, whereas in 1.2.19 it does not. Reversing the above commit restores the functionality.

It occurs on latest FF, Chrome and IE.

Other Comments:

[Narretz]

@petebacondarwin I assigned this to you, because you commited the change, is that okay?

[petebacondarwin]

@Narretz - that is fine. I will take a look today

[petebacondarwin]

@JoshSchreuder - This doesn't seem to be related to the commit you suggest. The plunker you provide is acting in the same way for all versions of 1.2.x. The reason is that the options contain numbers but you are setting the model to a string.
You can see this more clearly here: http://plnkr.co/edit/CimDFdu5Cv2rVKarTBWY?p=preview.

It may be that there is some other problem that your Plunker is not demonstrating very well. If so please open another issue with a different reproduction.

[JoshSchreuder]

@petebacondarwin thanks for having a look.

If you click the middle button in your Plunker using the default 1.2.19, the option is selected visibly (which is correct), but the DOM property selected is not added to the <option> element:

Now if you swap the Angular version to 1.2.18 (swap the commented out <script> tags in the Plunker), and click the same middle button again, the option is selected in the dropdown visibly, and the selected DOM property is correctly added to the element:

I don't think it's related to what is being set on the model in this case. I tried taking latest 1.2.21 angular.js build, and reversing the specific lines from the mentioned commit in OP. This resulted in selected property being added correctly, so I am fairly confident it is related to that commit.

[petebacondarwin]

I see. But if the select value is correct why do you care whether the option is selected? How does that affect your usage?

[JoshSchreuder]

@petebacondarwin it's a recommendation in accessibility standards to have a selected attribute on the <option> that is selected so that screenreaders can make use of this information I believe.

I was going through accessibility checking my app, and a lack of selected attributes was pointed out to me, so I went about checking when the regression happened.

[petebacondarwin]

I see, again. I'll take another look today
On 31 Jul 2014 06:47, "Josh Schreuder" notifications@github.com wrote:

@petebacondarwin https://github.com/petebacondarwin it's a
recommendation in accessibility standards to have a selected attribute on
the that is selected so that screenreaders can make use of this
information I believe.

I was going through accessibility checking my app, and a lack of selected
attributes was pointed out to me, so I went about checking when the
regression happened.

—
Reply to this email directly or view it on GitHub
#8366 (comment).

[petebacondarwin]

@JoshSchreuder - according to the jquery does, we should be using prop and that we should not expect the selected attribute on the <option> element to change - it should only show the initial state of the HTML and not the dynamic state.

See http://api.jquery.com/prop/

Can you link to the accessibility requirement that is suggesting otherwise?

[JoshSchreuder]

@petebacondarwin I'm using HTML Codesniffer (http://squizlabs.github.io/HTML_CodeSniffer/) which isn't the best way of working out accessibility issues, but the particular guideline it points to is here:
http://www.w3.org/TR/WCAG20-TECHS/H91

Which says that a <select> list should have an <option> element with the selected attribute set. Admittedly it doesn't indicate this should be dynamic, but I can't figure out a way with ng-options to set this initial selected attribute value, for either an empty model value, or a set model value.

Additionally, the spec quoted in jQuery docs (http://www.w3.org/TR/html401/interact/forms.html#h-17.6.1) says:

If no OPTION element has the selected attribute set, 
user agent behavior for choosing which option is initially selected is undefined.
...
Since user agent behavior differs, authors should ensure that each 
menu includes a default pre-selected OPTION.

[petebacondarwin]

OK, so we should ensure that the selected attribute is set when using ngOptions.

[JoshSchreuder]

Yep, I think that sounds like a good solution.