by Garrett Smith (dhtmlkitchen.com), edited by Frank Manno (frankmanno.com) with comments from David Mark, Richard Cornford, RobG, and Juriy Zaytsev.
FORM element, in most modern browsers,
implements many interfaces and has a rich set of features.
These features are exposed as properties of the form, such as
submit. Browsers also add their own non-standard features
ids of form
controls as properties to the
FORM. This results in
the properties of the form being replaced.
Browsers also may add
id's of other elements as properties to
document, and sometimes to the
object (or an object above the
global object in scope).
This non-standard behavior can result in replacement of
properties on other objects. The problems it causes are discussed in detail.
A problem occurs when a form control's
with the a property name of the
FORM object. For example:
<form action=""> <input type="text" name="name"> <input type="submit" name="submit"> </form>
The element with
the value of the
A similar type of conflict happens with the
submit method and the
name="submit'. Which will win?
In most cases, the form control wins and the
FORM's property is
replaced to have the value of the form control, or, if more than
one form control has that name, the
FORM's property is
replaced with a
NodeList containing those form controls.
However, in some cases, the
FORM's property is not replaced
to have the value of the form control with the same name. The examples in this page show that
the result depends on the browser, the property, and how the control is added.
The DOM 1 specification states:
FORMelement encompasses behavior similar to a collection and an element. It provides direct access to the contained
inputelements as well as the attributes of the
"Similar to a collection?"
What collection? Similar in what way?
The only standardized feature that is "similar to a collection" is
In most browsers, a form has direct access to all named form controls,
input type="image"), not just
Accessing controls as named or indexed properties is not standardized by the w3c DOM specification. It is a holdover feature from Netscape Navigator that was copied by Internet Explorer and since copied by every other major browser vendor.
Controls may be accessed directly off the form.
Given the following form:
<form action=""> <input type="text" name="a"> </form>
input name="a" may be retrieved in one of two ways, from the form
or from the
// Standard. document.forms.elements; document.forms.elements.a;
The control may be accessed directly off the form:
// non-standard. document.forms; document.forms.a;
Accessing a named control directly off the form can have undesirable results.
In a few browsers, removing a named control from the form will leave the named control as a property of the form.
This Simple leak example shows
that accessing a named element property directly from the
may cause the property to remain on the form, even after the element
has been removed from the DOM.
foo: [object HTMLInputElement] bar: undefined elements.foo: undefinedOpera 9.5, IE 6, Safari 2
foo: undefined bar: undefined elements.foo: undefined
Similarly, when a named
FORM element is removed from the
some browsers will keep that form name as a property of the
FORM controls as properties of the document is also nonstandard.
form's indexed form control properties may also appear out of order.
This behavior would not be compliant for the
it does not violate any standard for the form-as-a-collection (because
there is no standard).
Form-as-a-collection is unreliable and therefore should never be used.
provides programmers a safe place to access form controls.
elements collection contains the following properties:
namedItem, plus an ordinal
index property for each form control (excepting
input type="image" controls).
Some browsers also have a
tags property on the
When a form control is removed from the DOM, the
is updated; however, the property will still remain on the form in some browsers
(Mozilla bug 307415).
element removal example