W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Re: DOM HTML select.options.length should be read/write

From: Philippe Le Hegaret <plh@w3.org>
Date: 11 Feb 2002 14:43:23 -0500
To: Mark Hickenbottom <markhic@microsoft.com>
Cc: WWW DOM <www-dom@w3.org>
Message-Id: <1013456604.25718.114.camel@jfouffa>
The interface HTMLOptionsCollection was added in the draft. It is
equivalent to an HTMLCollection except that its length attribute is
read-write.

HTMLSelectElement.options is now of type HTMLOptionsCollection.
(this makes select.options.length read-write).

For consistency, HTMLSelectElement.length is now read-write.

It is allowed for implementation to not support these read-write
functionalities on those attributes. In such case, an exception
"NOT_SUPPORTED_ERR" will occur.

Regarding array manipulation in ECMAScript, this is language dependent
and cannot be part of the DOM Level 2 HTML specification. In any case,
we recommend using the manipulation methods provided by the DOM Level 2
Core (removeNode, appendChild, ...) to manipulate the children of the
select element.

Please, let us know if you are (or are not) satisfy with this decision,

Philippe,
for the DOM WG.

On Wed, 2001-12-19 at 02:29, Mark Hickenbottom wrote:
> >From O'Reilly's JavaScript Definitive Guide book:
> 
> The options[] property contains an array of Option objects, each of which describes one of the selection options presented within the Select object select. The options.length property specifies the number of elements in the array, as does the select.length property. See the Option object for further details. 
> 
> In JavaScript 1.1 [Navigator 3.0], you can modify the options displayed in a Select object in any of the following ways: 
> 
> If you set options.length to 0, all options in the Select object will be cleared. 
> 
> If you set options.length to a value less than the current value, then the number of options in the Select object will be decreased, and those and the end of the array will disappear. 
> 
> If you set an element in the options[] array to null, then that option will be removed from the Select object, and the elements above it in the array will be moved down, changing their indices, to occupy the new space in the array. 
> 
> If you create a new Option object with the Option() constructor (see the Option reference entry), you can add that option to the end of list of options in the Select object by assigning the newly created option to a position at the end of the options[] array. To do this, set options[options.length]. 
> 
> ----------------------------------------------------
> 
> Additionally, if you set options.length to a value higher than the current value, then the number of options in the Select object wll be increased by adding new options to the end of the array.
> 
> Each of the browsers that I tested, Netscape, Win IE, Mac IE, and WebTV, all work as above. I tested older versions of browsers as well as the latest versions of these browsers.
> 
> However, the DOM Level 2 HTML specification states that select.options.length is read-only.
> 
> This is a major incompatibility between DOM Level 0 and DOM Level 2. And, according to the DOM Level 2 specification, one of the goals of the HTML-specific DOM API is to address issues of backwards compatibility with the DOM Level 0.
> 
> If browsers made the length read-only, it would break literally tens of thousands of real world pages that expect length to be read/write. It is extremely common to clear a select of all options by setting the length to zero. Pages do this to clear a select and then repopulate it with new options. Pages also commonly modify options in the ways listed above.
> 
> Even dom-compliant browsers such as the latest version of Netscape keep the options.length read/write so that they remain compatible with the thousands of pages that dynamically create selects.
> 
> I would like to suggest that select.options.length (and its synonym select.length) be read/write, to remain compatible with the thousands of existing pages on the web.
Received on Monday, 11 February 2002 14:43:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:55 GMT