I've today discovered some strange behaviour in IE8's implementation of the DOM select element's JavaScript 'options' property.
Given the following HTML:
<select id="sel"><option value="val">An option</option></select>
And the javascript:
var sel = document.getElementById('sel');
alert(sel === sel.options); //alerts 'true' in IE8
Obviously, the clever fellow writing the select implementation on IE8 has written an indexer on the select element, and then had it expose itself as its own 'options' property to JavaScript.
My question is: is this expected functionality, according to the JavaScript language spec? Is this a known bug? Should I continue to treat the 'options' property as an object, rather than specifically an Array?
This is not how the select DOM element behaves under Firefox 3.5, Chrome 1.0, or Safari 3.1, where the 'options' property is exposed as a JavaScript array...
For reference, I came across this when I passed the 'options' property to the jQuery constructor in order to wrap its elements. Rather than the expected result of a jQuery object with X elements (as occured using Firefox, Chrome and Safari), I was returned a jQuery object with 1 element (the select element itself).
First of all, this is not related to JavaScript language, but rather to DOM :)
Nitpicking aside, DOM L2, for example, defines HTMLSelectElement as an object having options property. That property is defined to be of type HTMLOptionsCollection and represents - "The collection of OPTION elements contained by this element."
Now, to quote HTMLOptionsCollection:
An HTMLOptionsCollection is a list of nodes representing HTML option element. An individual node may be accessed by either ordinal index or the node's name or id attributes.
Note: Collections in the HTML DOM are assumed to be live meaning that they are automatically updated when the underlying document is changed.
Technically, there's nothing preventing HTMLSelectElement being equal to its HTMLOptionsCollection (not in DOM L2 specs, at least). Implementation is fully compliant as long as it matches standard behavior (i.e. elements are accessible by index or name/id and interface properties/methods - such as item and length - are implemented as specified).
Frankly, I don't see why you would care about this peculiarity. If accessing elements by index/name works, it shouldn't matter what options is equal to. As always, best bet is to design scripts in standard-compliant manner (and only then work around any known deficiencies).