This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Do you have a test case demonstrating what you mean?
here it is: http://jsfiddle.net/int32_t/nhmg6/10/
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.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2645 Yeah, I agree that we should converge on Firefox here.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2646
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.
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
FTR, r8341 fixed a couple of thinkos in that patch.