23574 2013-10-21 03:46:43 +0000 option[selected] behavior compatibility 2013-12-11 17:45:23 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element P2 normal Unsorted 1 tkent ian ian mike contributor oldest_to_newest 94982 0 tkent 2013-10-21 03:46:43 +0000 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element > Whenever an option element's selected attribute is added, its selectedness must be set to true. This rule is not compatible with major browsers. IE and Firefox seem to have dirty flags for option elements. If selectedness of an option element is changed by user action or selected IDL attribute, then setAttribute('selected', ...) and defaultSelected=true have no effect. As for Firefox, removeAttribute('selected') clears selectedness if the option element is not dirty. IE has no such behavior. Behavior of Safari and Chrome are broken. Safari doesn't update selectedness if 'selected' content attribute is set after parsing. Chrome sets selectedness whenever 'selected' content attribute is updated. Safari and Chrome are ignorable. IMO, the specification should follow IE or Firefox behavior. 95048 1 ian 2013-10-21 21:37:10 +0000 Do you have a test case demonstrating what you mean? 95059 2 tkent 2013-10-22 00:31:04 +0000 here it is: http://jsfiddle.net/int32_t/nhmg6/10/ 95060 3 tkent 2013-10-22 00:40:48 +0000 IMO, Firefox behavior looks reasonable. selected content attribute, defaultSelected IDL attribute, and selected IDL attribute of an OPTION element work like value content attribute, defaultValue IDL attribute, and value IDL attribute of an INPUT element in the 'value' value mode. 96517 4 ian 2013-11-19 17:06:24 +0000 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2645 Yeah, I agree that we should converge on Firefox here. 96518 5 ian 2013-11-19 17:06:41 +0000 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2646 96533 6 ian 2013-11-19 20:19:27 +0000 What I ended up with doesn't _quite_ match Firefox, in particular around things like whether the first option of a non-multiple, size=1 <select> that doesn't have its first item selected should end up considering that item dirty or not, and whether setting .selected to itself should set the elemnet to dirty or not (spec says yes, Firefox says no), and whether when an element with the attribute set has its state unset due to picking another element it should go dirty or not (Firefox says yes, spec says no). Basically Firefox's model is that dirtyness is set whenever the state of the element stops matching the attribute, whereas the spec's model now is that dirtiness is set when you try to explicitly set the selectedness in some way that is not via the content attribute. 96534 7 contributor 2013-11-19 20:20:55 +0000 Checked in as WHATWG revision r8297. Check-in comment: Move more towards the browsers for <option> selectedness vs dirtiness. This doesn't quite match any browser exactly, so all browsers would have to change to match it. If there's a reason (e.g. backcompat) to prefer a different model, please reopen the bug and let me know. http://html5.org/tools/web-apps-tracker?from=8296&to=8297 97465 8 ian 2013-12-11 17:45:23 +0000 FTR, r8341 fixed a couple of thinkos in that patch.