This is revision 1.5612.
A form-associated element can have a relationship
with a form
element, which is called the element's
form owner. If a form-associated element is
not associated with a form
element, its form
owner is said to be null.
A form-associated element is, by default, associated
with its nearest ancestor
form
element (as described
below), but may have a form
attribute specified to
override this.
This feature allows authors to work around the lack
of support for nested form
elements.
If a form-associated element has a form
attribute specified, then that
attribute's value must be the ID of a form
element in
the element's owner Document
.
The rules in this section are complicated by the
fact that although conforming documents will never contain nested
form
elements, it is quite possible (e.g. using a
script that performs DOM manipulation) to generate documents that
have such nested elements. They are also complicated by rules in the
HTML parser that, for historical reasons, can result in a
form-associated element being associated with a
form
element that is not its ancestor.
When a form-associated element is created, its form owner must be initialized to null (no owner).
When a form-associated element is to be associated with a form, its form owner must be set to that form.
When a form-associated element's ancestor chain
changes, e.g. because it or one of its ancestors was inserted or removed from a
Document
, then the user agent must reset the form
owner of that element. The HTML
parser overrides this requirement when inserting form
controls.
When a form-associated element's form
attribute is set, changed, or
removed, then the user agent must reset the form owner
of that element.
When a form-associated element has a form
attribute and the ID of any of the
elements in the Document
changes, then the user agent
must reset the form owner of that form-associated
element.
When a form-associated element has a form
attribute and an element with an
ID is inserted
into or removed from the Document
, then the
user agent must reset the form owner of that
form-associated element.
When the user agent is to reset the form owner of a form-associated element, it must run the following steps:
If the element's form owner is not null, and
the element's form
content
attribute is not present, and the element's form owner
is its nearest form
element ancestor after the change
to the ancestor chain, then do nothing, and abort these
steps.
Let the element's form owner be null.
If the element has a form
content attribute, then run these substeps:
If the first element in the
Document
to have an ID that is case-sensitively equal to the
element's form
content
attribute's value is a form
element, then associate the
form-associated element with that form
element.
Abort the "reset the form owner" steps.
Otherwise, if the form-associated element in
question has an ancestor form
element, then associate the
form-associated element with the nearest such ancestor
form
element.
Otherwise, the element is left unassociated.
In the following non-conforming snippet:
... <form id="a"> <div id="b"></div> </form> <script> document.getElementById('b').innerHTML = '<table><tr><td><form id="c"><input id="d"></table>' + '<input id="e">'; </script> ...
The form owner of "d" would be the inner nested form "c", while the form owner of "e" would be the outer form "a".
This happens as follows: First, the "e" node gets associated
with "c" in the HTML parser. Then, the innerHTML
algorithm moves the nodes
from the temporary document to the "b" element. At this point, the
nodes see their ancestor chain change, and thus all the "magic"
associations done by the parser are reset to normal ancestor
associations.
This example is a non-conforming document, though, as it is a
violation of the content models to nest form
elements.
form
Returns the element's form owner.
Returns null if there isn't one.
Form-associated
elements have a form
IDL attribute, which,
on getting, must return the element's form owner, or
null if there isn't one.