HTML
Living Standard — Last Updated 1 October 2025
Living Standard — Last Updated 1 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 " awesome@example.com"
(with leading whitespace) into an email field, the
user's input would be the string " awesome@example.com" but the browser's UI for
email fields might translate that into a value of "awesome@example.com" (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; // => trueSince 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:
<form action="addcomment.cgi" method=post>
<p><label>Comment: <input type=text name="comment" dirname="comment.dir" required></label></p>
<p><button name="mode" type=submit value="add">Post Comment</button></p>
</form>When the user submits the form, the user agent includes three fields, one called "comment", one called "comment.dir", and one called "mode"; so if the user types "Hello", the submission body might be something like:
comment=Hello&comment.dir=ltr&mode=add
If the user manually switches to a right-to-left writing direction and enters "مرحبا", the submission body might be something like:
comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl&mode=add
maxlength attributeA form
control maxlength attribute, controlled by the dirty value flag, declares a limit on the number of characters a
user can input. The number of characters is measured using length and, in the case
of textarea elements, with all newlines normalized to a single character (as opposed
to CRLF pairs).
If an element has its form control maxlength attribute specified, the attribute's value must be a valid
non-negative integer. If the attribute is specified and applying the rules for
parsing non-negative integers to its value results in a number, then that number is the
element's maximum allowed value length. If the attribute is omitted or parsing its
value results in an error, then there is no maximum allowed value length.
Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the length of the element's API value is greater than the element's maximum allowed value length, then the element is suffering from being too long.
User agents may prevent the user from causing the element's API value to be set to a value whose length is greater than the element's maximum allowed value length.
In the case of textarea elements, the API value and value
differ. In particular, newline normalization is applied
before the maximum allowed value length is checked (whereas the textarea
wrapping transformation is not applied).
minlength attributeA form
control minlength attribute, controlled by the dirty value flag, declares a lower bound on the number of
characters a user can input. The "number of characters" is measured using length and,
in the case of textarea elements, with all newlines normalized to a single character
(as opposed to CRLF pairs).
The minlength attribute does not imply the
required attribute. If the form control has no required attribute, then the value can still be omitted; the minlength attribute only kicks in once the user has entered a
value at all. If the empty string is not allowed, then the required
attribute also needs to be set.
If an element has its form control minlength attribute specified, the attribute's value must be a valid
non-negative integer. If the attribute is specified and applying the rules for
parsing non-negative integers to its value results in a number, then that number is the
element's minimum allowed value length. If the attribute is omitted or parsing its
value results in an error, then there is no minimum allowed value length.
If an element has both a maximum allowed value length and a minimum allowed value length, the minimum allowed value length must be smaller than or equal to the maximum allowed value length.
Constraint validation: If an element has a minimum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), its value is not the empty string, and the length of the element's API value is less than the element's minimum allowed value length, then the element is suffering from being too short.
In this example, there are four text controls. The first is required, and has to be at least 5 characters long. The other three are optional, but if the user fills one in, the user has to enter at least 10 characters.
<form action="/events/menu.cgi" method="post">
<p><label>Name of Event: <input required minlength=5 maxlength=50 name=event></label></p>
<p><label>Describe what you would like for breakfast, if anything:
<textarea name="breakfast" minlength="10"></textarea></label></p>
<p><label>Describe what you would like for lunch, if anything:
<textarea name="lunch" minlength="10"></textarea></label></p>
<p><label>Describe what you would like for dinner, if anything:
<textarea name="dinner" minlength="10"></textarea></label></p>
<p><input type=submit value="Submit Request"></p>
</form>disabled attributeSupport in all current engines.
Support in all current engines.
Support in all current engines.
Support in all current engines.
Support in all current engines.
The disabled content attribute is a boolean
attribute.
The disabled attribute for
option elements and the disabled
attribute for optgroup elements are defined separately.
A form control is disabled if any of the following are true:
the element is a button, input, select,
textarea, or form-associated custom element, and the disabled attribute is specified on this element (regardless of
its value); or
the element is a descendant of a fieldset element whose disabled attribute is specified, and is not a
descendant of that fieldset element's first legend element child, if
any.
A form control that is disabled must prevent any
click events that are queued
on the user interaction task source from being dispatched on the element.
Being disabled does not prevent all modifications to the form control. For example, the control's value or checkedness could be modified programmatically from JavaScript. Or, they could be indirectly modified by user action, e.g., if other non-disabled elements in the control's radio button group were modified.
Constraint validation: If an element is disabled, it is barred from constraint validation.
Element/form#Attributes_for_form_submission
Support in all current engines.
Attributes for form submission can be specified both on form elements
and on submit buttons (elements that represent buttons
that submit forms, e.g. an input element whose type attribute is in the Submit Button state).
The attributes for form submission that may be specified on form
elements are action, enctype, method, novalidate, and target.
The corresponding attributes for form submission that may be specified on submit buttons are formaction, formenctype, formmethod, formnovalidate, and formtarget. When omitted, they default to the values given on
the corresponding attributes on the form element.
Support in all current engines.
The action and
formaction
content attributes, if specified, must have a value that is a valid non-empty URL
potentially surrounded by spaces.
The action of an element is the value of the element's
formaction attribute, if the element is a submit button and has such an attribute, or the value of its
form owner's action attribute, if it has
one, or else the empty string.
Support in all current engines.
The method and
formmethod
content attributes are enumerated attributes with the
following keywords and states:
| Keyword | State | Brief description |
|---|---|---|
get
| GET | Indicates the form will use the HTTP GET method.
|
post
| POST | Indicates the form will use the HTTP POST method.
|
dialog
| Dialog | Indicates the form is intended to close the dialog box in which
the form finds itself, if any, and otherwise not submit.
|
The method attribute's missing value default and invalid value default
are both the GET state.
The formmethod attribute has no missing value default, and its invalid value
default is the GET state.
The method of an element is one of those states. If the
element is a submit button and has a formmethod attribute, then the element's method is that attribute's state; otherwise, it is the form
owner's method attribute's state.
Here the method attribute is used to explicitly specify
the default value, "get", so that the search
query is submitted in the URL:
<form method="get" action="/search.cgi">
<p><label>Search terms: <input type=search name=q></label></p>
<p><input type=submit></p>
</form>On the other hand, here the method attribute is used to
specify the value "post", so that the user's
message is submitted in the HTTP request's body:
<form method="post" action="/post-message.cgi">
<p><label>Message: <input type=text name=m></label></p>
<p><input type=submit value="Submit message"></p>
</form>In this example, a form is used with a dialog. The method attribute's "dialog" keyword is used to have the dialog
automatically close when the form is submitted.
<dialog id="ship">
<form method=dialog>
<p>A ship has arrived in the harbour.</p>
<button type=submit value="board">Board the ship</button>
<button type=submit value="call">Call to the captain</button>
</form>
</dialog>
<script>
var ship = document.getElementById('ship');
ship.showModal();
ship.onclose = function (event) {
if (ship.returnValue == 'board') {
// ...
} else {
// ...
}
};
</script>Support in all current engines.
The enctype and
formenctype
content attributes are enumerated attributes with the
following keywords and states:
application/x-www-form-urlencoded" keyword and
corresponding state.multipart/form-data" keyword and corresponding
state.text/plain" keyword and corresponding state.The attribute's missing value default and invalid value default are both the application/x-www-form-urlencoded state.
The formenctype attribute has no missing value default, and its invalid value
default is the application/x-www-form-urlencoded state.
The enctype of an element is one of those three states.
If the element is a submit button and has a formenctype attribute, then the element's enctype is that attribute's state; otherwise, it is the
form owner's enctype attribute's state.
Support in all current engines.
The target and
formtarget
content attributes, if specified, must have values that are valid navigable target names or keywords.
Support in all current engines.
The novalidate and formnovalidate content attributes are boolean attributes. If present, they indicate that the form is
not to be validated during submission.
The no-validate state of an element is true if the
element is a submit button and the element's formnovalidate attribute is present, or if the element's
form owner's novalidate attribute is present,
and false otherwise.
This attribute is useful to include "save" buttons on forms that have validation constraints, to allow users to save their progress even though they haven't fully entered the data in the form. The following example shows a simple form that has two required fields. There are three buttons: one to submit the form, which requires both fields to be filled in; one to save the form so that the user can come back and fill it in later; and one to cancel the form altogether.
<form action="editor.cgi" method="post">
<p><label>Name: <input required name=fn></label></p>
<p><label>Essay: <textarea required name=essay></textarea></label></p>
<p><input type=submit name=submit value="Submit essay"></p>
<p><input type=submit formnovalidate name=save value="Save essay"></p>
<p><input type=submit formnovalidate name=cancel value="Cancel"></p>
</form>Support in all current engines.
The action
getter steps are:
If attribute is null or attribute's value is the empty string, then return this's node document's URL.
Let urlString be the result of encoding-parsing-and-serializing a URL given attribute's value, relative to this's node document.
If urlString is not failure, then return urlString.
Return attribute's value, converted to a scalar value string.
The formAction getter steps are:
Let attribute be this's formaction attribute.
If attribute is null or attribute's value is the empty string, then return this's node document's URL.
Let urlString be the result of encoding-parsing-and-serializing a URL given attribute's value, relative to this's node document.
If urlString is not failure, then return urlString.
Return attribute's value, converted to a scalar value string.
Support in all current engines.
Support in all current engines.
Support in all current engines.
The method and
enctype IDL
attributes must reflect the respective content attributes of the same name,
limited to only known values. The encoding IDL attribute must reflect the enctype content attribute, limited to only known
values. The formEnctype IDL attribute must reflect the
formenctype content attribute, limited to only
known values. The formMethod IDL attribute must reflect the
formmethod content attribute, limited to only known
values.
autocomplete attributeSupport in all current engines.
User agents sometimes have features for helping users fill forms in, for example prefilling the
user's address based on earlier user input. The autocomplete content attribute can be used to hint to
the user agent how to, or indeed whether to, provide such a feature.
There are two ways this attribute is used. When wearing the autofill expectation
mantle, the autocomplete attribute describes what
input is expected from users. When wearing the autofill anchor mantle, the autocomplete attribute describes the meaning of the given
value.
On an input element whose type attribute is
in the state, the autocomplete attribute wears the autofill anchor
mantle. In all other cases, it wears the autofill expectation mantle.
When wearing the autofill expectation mantle, the autocomplete attribute, if specified, must have a value that
is an ordered set of space-separated tokens consisting of either a single token that
is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII
case-insensitive match for the string "on",
or autofill detail tokens.
When wearing the autofill anchor
mantle, the autocomplete attribute, if specified, must have a value that is an ordered set of
space-separated tokens consisting of just autofill detail tokens (i.e. the
"on" and "off" keywords are not allowed).
Autofill detail tokens are the following, in the order given below:
Optionally, a token whose first eight characters are an ASCII case-insensitive
match for the string "section-", meaning that the field belongs to
the named group.
For example, if there are two shipping addresses in the form, then they could be marked up as:
<fieldset>
<legend>Ship the blue gift to...</legend>
<p> <label> Address: <textarea name=ba autocomplete="section-blue shipping street-address"></textarea> </label>
<p> <label> City: <input name=bc autocomplete="section-blue shipping address-level2"> </label>
<p> <label> Postal Code: <input name=bp autocomplete="section-blue shipping postal-code"> </label>
</fieldset>
<fieldset>
<legend>Ship the red gift to...</legend>
<p> <label> Address: <textarea name=ra autocomplete="section-red shipping street-address"></textarea> </label>
<p> <label> City: <input name=rc autocomplete="section-red shipping address-level2"> </label>
<p> <label> Postal Code: <input name=rp autocomplete="section-red shipping postal-code"> </label>
</fieldset>Optionally, a token that is an ASCII case-insensitive match for one of the following strings:
shipping", meaning the field is part of the
shipping address or contact information
billing", meaning the field is part of the
billing address or contact information
Either of the following two options:
A token that is an ASCII case-insensitive match for one of the following autofill field names, excluding those that are inappropriate for the control:
name"
honorific-prefix"
given-name"
additional-name"
family-name"
honorific-suffix"
nickname"
username"
new-password"
current-password"
one-time-code"
organization-title"
organization"
street-address"
address-line1"
address-line2"
address-line3"
address-level4"
address-level3"
address-level2"
address-level1"
country"
country-name"
postal-code"
cc-name"
cc-given-name"
cc-additional-name"
cc-family-name"
cc-number"
cc-exp"
cc-exp-month"
cc-exp-year"
cc-csc"
cc-type"
transaction-currency"
transaction-amount"
language"
bday"
bday-day"
bday-month"
bday-year"
sex"
url"
photo"
(See the table below for descriptions of these values.)
The following, in the given order:
Optionally, a token that is an ASCII case-insensitive match for one of the following strings:
home", meaning the field is for contacting
someone at their residence
work", meaning the field is for contacting
someone at their workplace
mobile", meaning the
field is for contacting someone regardless of location
fax", meaning the field describes a fax
machine's contact details
pager", meaning the field describes a
pager's or beeper's contact details
A token that is an ASCII case-insensitive match for one of the following autofill field names, excluding those that are inappropriate for the control:
tel"
tel-country-code"
tel-national"
tel-area-code"
tel-local"
tel-local-prefix"
tel-local-suffix"
tel-extension"
email"
impp"
(See the table below for descriptions of these values.)
Optionally, a token that is an ASCII case-insensitive match for the string
"webauthn", meaning the user agent
should show public key credentials available via
conditional mediation when the user interacts with the
form control. webauthn is only valid for
input and textarea elements.
As noted earlier, the meaning of the attribute and its keywords depends on the mantle that the attribute is wearing.
The "off" keyword indicates either that the control's
input data is particularly sensitive (for example the activation code for a nuclear weapon); or
that it is a value that will never be reused (for example a one-time-key for a bank login) and
the user will therefore have to explicitly enter the data each time, instead of being able to
rely on the UA to prefill the value for them; or that the document provides its own autocomplete
mechanism and does not want the user agent to provide autocompletion values.
The "on" keyword indicates that the user agent is
allowed to provide the user with autocompletion values, but does not provide any further
information about what kind of data the user might be expected to enter. User agents would have
to use heuristics to decide what autocompletion values to suggest.
The autofill field listed above indicate that the user agent is allowed to provide the user with autocompletion values, and specifies what kind of value is expected. The meaning of each such keyword is described in the table below.
If the autocomplete attribute is omitted, the default
value corresponding to the state of the element's form owner's autocomplete attribute is used instead (either "on" or "off"). If there is no form owner, then the
value "on" is used.
The autofill field listed above indicate that the value of the particular kind of value specified is that value provided for this element. The meaning of each such keyword is described in the table below.
In this example the page has explicitly specified the currency and amount of the transaction. The form requests a credit card and other billing details. The user agent could use this information to suggest a credit card that it knows has sufficient balance and that supports the relevant currency.
<form method=post action="step2.cgi">
<input type=hidden autocomplete=transaction-currency value="CHF">
<input type=hidden autocomplete=transaction-amount value="15.00">
<p><label>Credit card number: <input type=text inputmode=numeric autocomplete=cc-number></label>
<p><label>Expiry Date: <input type=month autocomplete=cc-exp></label>
<p><input type=submit value="Continue...">
</form>The autofill field keywords relate to each other as described in the table below. Each field name
listed on a row of this table corresponds to the meaning given in the cell for that row in the
column labeled "Meaning". Some fields correspond to subparts of other fields; for example, a
credit card expiry date can be expressed as one field giving both the month and year of expiry
("cc-exp"), or as two fields, one giving the
month ("cc-exp-month") and one the year
("cc-exp-year"). In such cases, the names of
the broader fields cover multiple rows, in which the narrower fields are defined.
Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore more flexible.
Some fields are only appropriate for certain form controls. An autofill field name is inappropriate for a control if the control does not belong to the group listed for that autofill field in the fifth column of the first row describing that autofill field in the table below. What controls fall into each group is described below the table.
| Field name | Meaning | Canonical Format | Canonical Format Example | Control group | |||
|---|---|---|---|---|---|---|---|
"name"
| Full name | Free-form text, no newlines | Sir Timothy John Berners-Lee, OM, KBE, FRS, FREng, FRSA | Text | |||
"honorific-prefix"
| Prefix or title (e.g. "Mr.", "Ms.", "Dr.", "Mlle") | Free-form text, no newlines | Sir | Text | |||
"given-name"
| Given name (in some Western cultures, also known as the first name) | Free-form text, no newlines | Timothy | Text | |||
"additional-name"
| Additional names (in some Western cultures, also known as middle names, forenames other than the first name) | Free-form text, no newlines | John | Text | |||
"family-name"
| Family name (in some Western cultures, also known as the last name or surname) | Free-form text, no newlines | Berners-Lee | Text | |||
"honorific-suffix"
| Suffix (e.g. "Jr.", "B.Sc.", "MBASW", "II") | Free-form text, no newlines | OM, KBE, FRS, FREng, FRSA | Text | |||
"nickname"
| Nickname, screen name, handle: a typically short name used instead of the full name | Free-form text, no newlines | Tim | Text | |||
"organization-title"
| Job title (e.g. "Software Engineer", "Senior Vice President", "Deputy Managing Director") | Free-form text, no newlines | Professor | Text | |||
"username"
| A username | Free-form text, no newlines | timbl | Username | |||
"new-password"
| A new password (e.g. when creating an account or changing a password) | Free-form text, no newlines | GUMFXbadyrS3 | Password | |||
"current-password"
| The current password for the account identified by the username field (e.g. when logging in)
| Free-form text, no newlines | qwerty | Password | |||
"one-time-code"
| One-time code used for verifying user identity | Free-form text, no newlines | 123456 | Password | |||
"organization"
| Company name corresponding to the person, address, or contact information in the other fields associated with this field | Free-form text, no newlines | World Wide Web Consortium | Text | |||
"street-address"
| Street address (multiple lines, newlines preserved) | Free-form text | 32 Vassar Street MIT Room 32-G524 | Multiline | |||
"address-line1"
| Street address (one line per field) | Free-form text, no newlines | 32 Vassar Street | Text | |||
"address-line2"
| Free-form text, no newlines | MIT Room 32-G524 | Text | ||||
"address-line3"
| Free-form text, no newlines | Text | |||||
"address-level4"
| The most fine-grained administrative level, in addresses with four administrative levels | Free-form text, no newlines | Text | ||||
"address-level3"
| The third administrative level, in addresses with three or more administrative levels | Free-form text, no newlines | Text | ||||
"address-level2"
| The second administrative level, in addresses with two or more administrative levels; in the countries with two administrative levels, this would typically be the city, town, village, or other locality within which the relevant street address is found | Free-form text, no newlines | Cambridge | Text | |||
"address-level1"
| The broadest administrative level in the address, i.e. the province within which the locality is found; for example, in the US, this would be the state; in Switzerland it would be the canton; in the UK, the post town | Free-form text, no newlines | MA | Text | |||
"country"
| Country code | Valid ISO 3166-1-alpha-2 country code [ISO3166] | US | Text | |||
"country-name"
| Country name | Free-form text, no newlines; derived from country in some cases
| US | Text | |||
"postal-code"
| Postal code, post code, ZIP code, CEDEX code (if CEDEX, append "CEDEX", and the arrondissement, if relevant, to the address-level2 field)
| Free-form text, no newlines | 02139 | Text | |||
"cc-name"
| Full name as given on the payment instrument | Free-form text, no newlines | Tim Berners-Lee | Text | |||
"cc-given-name"
| Given name as given on the payment instrument (in some Western cultures, also known as the first name) | Free-form text, no newlines | Tim | Text | |||
"cc-additional-name"
| Additional names given on the payment instrument (in some Western cultures, also known as middle names, forenames other than the first name) | Free-form text, no newlines | Text | ||||
"cc-family-name"
| Family name given on the payment instrument (in some Western cultures, also known as the last name or surname) | Free-form text, no newlines | Berners-Lee | Text | |||
"cc-number"
| Code identifying the payment instrument (e.g. the credit card number) | ASCII digits | 4114360123456785 | Text | |||
"cc-exp"
| Expiration date of the payment instrument | Valid month string | 2014-12 | Month | |||
"cc-exp-month"
| Month component of the expiration date of the payment instrument | Valid integer in the range 1..12 | 12 | Numeric | |||
"cc-exp-year"
| Year component of the expiration date of the payment instrument | Valid integer greater than zero | 2014 | Numeric | |||
"cc-csc"
| Security code for the payment instrument (also known as the card security code (CSC), card validation code (CVC), card verification value (CVV), signature panel code (SPC), credit card ID (CCID), etc.) | ASCII digits | 419 | Text | |||
"cc-type"
| Type of payment instrument | Free-form text, no newlines | Visa | Text | |||
"transaction-currency"
| The currency that the user would prefer the transaction to use | ISO 4217 currency code [ISO4217] | GBP | Text | |||
"transaction-amount"
| The amount that the user would like for the transaction (e.g. when entering a bid or sale price) | Valid floating-point number | 401.00 | Numeric | |||
"language"
| Preferred language | Valid BCP 47 language tag [BCP47] | en | Text | |||
"bday"
| Birthday | Valid date string | 1955-06-08 | Date | |||
"bday-day"
| Day component of birthday | Valid integer in the range 1..31 | 8 | Numeric | |||
"bday-month"
| Month component of birthday | Valid integer in the range 1..12 | 6 | Numeric | |||
"bday-year"
| Year component of birthday | Valid integer greater than zero | 1955 | Numeric | |||
"sex"
| Gender identity (e.g. Female, Fa'afafine) | Free-form text, no newlines | Male | Text | |||
"url"
| Home page or other web page corresponding to the company, person, address, or contact information in the other fields associated with this field | Valid URL string | https://www.w3.org/People/Berners-Lee/ | URL | |||
"photo"
| Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field | Valid URL string | https://www.w3.org/Press/Stock/Berners-Lee/2001-europaeum-eighth.jpg | URL | |||
"tel"
| Full telephone number, including country code | ASCII digits and U+0020 SPACE characters, prefixed by a U+002B PLUS SIGN character (+) | +1 617 253 5702 | Tel | |||
"tel-country-code"
| Country code component of the telephone number | ASCII digits prefixed by a U+002B PLUS SIGN character (+) | +1 | Text | |||
"tel-national"
| Telephone number without the county code component, with a country-internal prefix applied if applicable | ASCII digits and U+0020 SPACE characters | 617 253 5702 | Text | |||
"tel-area-code"
| Area code component of the telephone number, with a country-internal prefix applied if applicable | ASCII digits | 617 | Text | |||
"tel-local"
| Telephone number without the country code and area code components | ASCII digits | 2535702 | Text | |||
"tel-local-prefix"
| First part of the component of the telephone number that follows the area code, when that component is split into two components | ASCII digits | 253 | Text | |||
"tel-local-suffix"
| Second part of the component of the telephone number that follows the area code, when that component is split into two components | ASCII digits | 5702 | Text | |||
"tel-extension"
| Telephone number internal extension code | ASCII digits | 1000 | Text | |||
"email"
| Email address | Valid email address | timbl@w3.org | Username | |||
"impp"
| URL representing an instant messaging protocol endpoint (for example, "aim:goim?screenname=example" or "xmpp:fred@example.net")
| Valid URL string | irc://example.org/timbl,isuser | URL | |||
The groups correspond to controls as follows:
input elements with a type attribute in the Hidden state
input elements with a type attribute in the Text state
input elements with a type attribute in the Search state
textarea elements
select elements
input elements with a type attribute in the