Form-as-a-collection is problematic for implementors and should be a concern for developers (because bugs can occur when unsafe names are used).
The idea of creating properties on a form creates a conflict. In Opera, the same key may appear twice in a for in loop. Opera, For In Loop, Same Key Appears Twice.
The elements collection is a safe alternative.
By deprecating the non-standard mystery "similar to a collection"
behavior of a form, authors would be discouraged from using it.
Developers can still safely access the properties directly from the elements
collection.
There is no need to standardize this.
The HTML 5 draft has merged in much of the Web Forms 2.0 specification, which attempted to standardize some of the browser inconsistencies, strange behavior, and bugs.
This example contains a FORM
element with two form controls,
one named "length", the other "toString". A click callback is added to the
FORM
's length
property. The body of the function calls
the alert
function with the FORM
.
The callback tries to alert
the FORM
but throws an error when the alert
function
attempts to call the form's toString
property, which was shadowed by a form control.
Many browsers make HTMLCollection
collection a callable object.
When called, document.forms(x)
returns a form element whose name
,
id
, or index
matches the supplied argument x
.
Callable HTMLCollection Example
The DOM does not standardize collections to be callable. There isn't a good reason to call a collection. The property access operators provide a standard, cross-browser alternative. Callable collections are not implented in Mozilla. This feature does not appear to be considered for inclusion in HTML 5 or Web IDL.
Many browsers implement Map-like quality on NodeList
.
In these browsers, elements are accessible off the NodeList
by their ID.
This behavior is nonstandard and may be present, but should not be used. It is one innovation of Internet Explorer, copied in Safari, Opera, and perhaps elsewhere.
Implementation developers and specifications authors must be aware of the permanence of API Design. We should all be cognizant of the impact that an API has on the future.