HTML
Living Standard — Last Updated 17 October 2025
Living Standard — Last Updated 17 October 2025
name attributedirname attributemaxlength attributeminlength attributedisabled attributeSubmitEvent interfaceFormDataEvent interfaceMost form controls have a value and a checkedness. (The latter is only used by input
elements.) These are used to describe how the user interacts with the control.
A control's value is its internal state. As such, it might not match the user's current input.
For instance, if a user enters the word "three" into a numeric field that expects digits, the user's input would
be the string "three" but the control's value would remain
unchanged. Or, if a user enters the email address " [email protected]"
(with leading whitespace) into an email field, the
user's input would be the string " [email protected]" but the browser's UI for
email fields might translate that into a value of "[email protected]" (without the leading whitespace).
input
and textarea elements have a dirty value flag.
This is used to track the interaction between the value and
default value. If it is false, value mirrors the default
value. If it is true, the default value is ignored.
Some form controls also have an optional value. This largely mirrors the value but doesn't normalize to an empty string. This ought to be used sparingly, you generally want value.
input, textarea, and select elements have a
user validity boolean. It is initially set to false.
To define the behavior of constraint validation in the face of the input
element's multiple attribute, input elements
can also have separately defined values.
To define the behavior of the maxlength and minlength attributes, as well as other APIs specific to the
textarea element, all form control with a value also have an algorithm for obtaining an API value. By
default this algorithm is to simply return the control's value.
The select element does not have a value;
the selectedness of its option
elements is what is used instead.
A form control can be designated as mutable.
This determines (by means of definitions and requirements in this specification that rely on whether an element is so designated) whether or not the user can modify the value or checkedness of a form control, or whether or not a control can be automatically prefilled.
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 has an associated parser inserted flag.
Support in all current engines.
Support in all current engines.
A form-associated element is, by default, associated with its nearest ancestor form element (as described
below), but, if it is listed, 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 listed 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
tree.
The rules in this section are complicated by the fact that although conforming
documents or trees will never contain nested form
elements, it is quite possible (e.g., using a script that performs DOM manipulation) to generate
trees 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 listed 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 listed form-associated element has a
form attribute and the ID of
any of the elements in the tree changes, then the user agent must reset the
form owner of that form-associated element.
When a listed form-associated element has a
form attribute and an element with an ID is inserted
into or removed from the
Document, or its HTML element moving steps are run, then the user agent
must reset the form owner of that form-associated element.
The form owner is also reset by the HTML element insertion steps, HTML element removing steps, and HTML element moving steps.
To reset the form owner of a form-associated element element:
Unset element's parser inserted flag.
If all of the following are true:
element's form owner is not null;
element is not listed or its form content attribute is not present; and
element's form owner is its nearest form element
ancestor after the change to the ancestor chain,
then return.
Set element's form owner to null.
If element is listed, has a form content attribute, and is connected, then:
If the first element in element's tree, in tree
order, to have an ID that is identical to
element's form content attribute's value, is a
form element, then associate the
element with that form element.
Otherwise, if element has an ancestor form element, then associate element with the nearest such
ancestor form element.
In the following non-conforming snippet
...
< form id = "a" >
< div id = "b" ></ div >
</ form >
< script >
document. getElementById( 'b' ). innerHTML =
'<table><tr><td></form><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, and there is a parse error for the </form> tag.
element.formSupport in all current engines.
Support in all current engines.
Returns the element's form owner.
Returns null if there isn't one.
Listed form-associated elements except for form-associated custom elements have a form IDL attribute, which, on getting, must return the
element's form owner, or null if there isn't one.
Support in all current engines.
Form-associated custom elements don't have
form IDL attribute. Instead, their
ElementInternals object has a form IDL attribute. On getting, it must throw a
"NotSupportedError" DOMException if the target element is not a form-associated custom
element. Otherwise, it must return the element's form owner, or null if there
isn't one.
name attributeSupport in all current engines.
The name content attribute gives the name of the form control, as
used in form submission and in the form element's elements object. If the attribute is specified, its value must
not be the empty string or isindex.
A number of user agents historically implemented special support for first-in-form
text controls with the name isindex, and this specification previously
defined related user agent requirements for it. However, some user agents subsequently dropped
that special support, and the related requirements were removed from this specification. So, to
avoid problematic reinterpretations in legacy user agents, the name isindex
is no longer allowed.
Other than isindex, any non-empty value for name is allowed. An ASCII case-insensitive match for
the name _charset_ is special: if used as
the name of a control with no value attribute, then during submission the value attribute is automatically given a value consisting of the
submission character encoding.
DOM clobbering is a common cause of security issues. Avoid using the names of
built-in form properties with the name content attribute.
In this example, the input element overrides the built-in method property:
let form = document. createElement( "form" );
let input = document. createElement( "input" );
form. appendChild( input);
form. method; // => "get"
input. name = "method" ; // DOM clobbering occurs here
form. method === input; // => true Since the input name takes precedence over built-in form properties, the JavaScript reference
form.method will point to the input element named "method"
instead of the built-in method property.
dirname attributeSupport in all current engines.
The dirname
attribute on a form control element enables the submission of the directionality of
the element, and gives the name of the control that contains this value during form
submission. If such an attribute is specified, its value must not be the empty string.
In this example, a form contains a text control and a submission button: