HTML: The Living Standard

Edition for Web Developers — Last Updated 17 December 2024

1. 1. 1. 4.10.17 Form control infrastructure
         1. 4.10.17.1 A form control's value
         2. 4.10.17.2 Mutability
         3. 4.10.17.3 Association of controls and forms
      2. 4.10.18 Attributes common to form controls
         1. 4.10.18.1 Naming form controls: the name attribute
         2. 4.10.18.2 Submitting element directionality: the dirname attribute
         3. 4.10.18.3 Limiting user input length: the maxlength attribute
         4. 4.10.18.4 Setting minimum input length requirements: the minlength attribute
         5. 4.10.18.5 Enabling and disabling form controls: the disabled attribute
         6. 4.10.18.6 Form submission attributes
         7. 4.10.18.7 Autofill
            1. 4.10.18.7.1 Autofilling form controls: the autocomplete attribute
      3. 4.10.19 APIs for the text control selections
      4. 4.10.20 Constraints
         1. 4.10.20.1 The constraint validation API
         2. 4.10.20.2 Security
      5. 4.10.21 Form submission
         1. 4.10.21.1 URL-encoded form data
         2. 4.10.21.2 Multipart form data
         3. 4.10.21.3 Plain text form data
         4. 4.10.21.4 The SubmitEvent interface
         5. 4.10.21.5 The FormDataEvent interface

4.10.17 Form control infrastructure

4.10.17.1 A form control's value

Most 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.

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.

4.10.17.2 Mutability

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.

4.10.17.3 Association of controls and forms

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.

A form-associated element is, by default, associated with its ancestor form element, 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.

element.form

Returns the element's form owner.

Returns null if there isn't one.

4.10.18 Attributes common to form controls

4.10.18.1 Naming form controls: the name attribute

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 Hidden control with no value attribute, then during submission the value attribute is automatically given a value consisting of the submission character encoding.

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

4.10.18.2 Submitting element directionality: the dirname attribute

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.

<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>

comment=Hello&comment.dir=ltr&mode=add

comment=%D9%85%D8%B1%D8%AD%D8%A8%D8%A7&comment.dir=rtl&mode=add

4.10.18.3 Limiting user input length: the maxlength attribute

A 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.

4.10.18.4 Setting minimum input length requirements: the minlength attribute

A 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.

<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>

4.10.18.5 Enabling and disabling form controls: the disabled attribute

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.

4.10.18.6 Form submission attributes

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.

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.

The method and formmethod content attributes are enumerated attributes with the following keywords and states:

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.

<form method="get" action="/search.cgi">
 <p><label>Search terms: <input type=search name=q></label></p>
 <p><input type=submit></p>
</form>

<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>

<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>

The enctype and formenctype content attributes are enumerated attributes with the following keywords and states:

• The "application/x-www-form-urlencoded" keyword and corresponding state.
• The "multipart/form-data" keyword and corresponding state.
• The "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.

The target and formtarget content attributes, if specified, must have values that are valid navigable target names or keywords.

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.

<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>

4.10.18.7 Autofill

4.10.18.7.1 Autofilling form controls: the autocomplete attribute

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 Hidden 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:

1. 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>

2. 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

3. 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:

     1. 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

     2. 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.)

4. 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.

When wearing the autofill expectation mantle...

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.

When wearing the autofill anchor mantle...

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.

The groups correspond to controls as follows:

Text

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

Multiline

input elements with a type attribute in the Hidden state

textarea elements

select elements

Password

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

input elements with a type attribute in the Password state

textarea elements

select elements

URL

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

input elements with a type attribute in the URL state

textarea elements

select elements

Username

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

input elements with a type attribute in the Email state

textarea elements

select elements

Tel

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

input elements with a type attribute in the Telephone state

textarea elements

select elements

Numeric

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

input elements with a type attribute in the Number state

textarea elements

select elements

Month

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

input elements with a type attribute in the Month state

textarea elements

select elements

Date

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

input elements with a type attribute in the Date state

textarea elements

select elements

Address levels: The "address-level1" – "address-level4" fields are used to describe the locality of the street address. Different locales have different numbers of levels. For example, the US uses two levels (state and town), the UK uses one or two depending on the address (the post town, and in some cases the locality), and China can use three (province, city, district). The "address-level1" field represents the widest administrative division. Different locales order the fields in different ways; for example, in the US the town (level 2) precedes the state (level 1); while in Japan the prefecture (level 1) precedes the city (level 2) which precedes the district (level 3). Authors are encouraged to provide forms that are presented in a way that matches the country's conventions (hiding, showing, and rearranging fields accordingly as the user changes the country).

4.10.19 APIs for the text control selections

The input and textarea elements define several attributes and methods for handling their selection. Their shared algorithms are defined here.

element.select()

✔MDN

HTMLInputElement/select

Support in all current engines.

Firefox1+Safari1+Chrome1+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer5.5+

---

Firefox Android?Safari iOS?Chrome Android?WebView Android?Samsung Internet?Opera Android12.1+

HTMLInputElement/select

Selects everything in the text control.

element.selectionStart [ = value ]

Returns the offset to the start of the selection.

Can be set, to change the start of the selection.

element.selectionEnd [ = value ]

Returns the offset to the end of the selection.

Can be set, to change the end of the selection.

element.selectionDirection [ = value ]

Returns the current direction of the selection.

Can be set, to change the direction of the selection.

The possible values are "forward", "backward", and "none".

element.setSelectionRange(start, end [, direction])

Changes the selection to cover the given substring in the given direction. If the direction is omitted, it will be reset to be the platform default (none or forward).

element.setRangeText(replacement [, start, end [, selectionMode ] ])

Replaces a range of text with the new text. If the start and end arguments are not provided, the range is assumed to be the selection.

The final argument determines how the selection will be set after the text has been replaced. The possible values are:

"select"

Selects the newly inserted text.

"start"

Moves the selection to just before the inserted text.

"end"

Moves the selection to just after the selected text.

"preserve"

Attempts to preserve the selection. This is the default.

var selectionText = control.value.substring(control.selectionStart, control.selectionEnd);

var oldStart = control.selectionStart;
var oldEnd = control.selectionEnd;
var oldDirection = control.selectionDirection;
var prefix = "http://";
control.value = prefix + control.value;
control.setSelectionRange(oldStart + prefix.length, oldEnd + prefix.length, oldDirection);

4.10.20 Constraints

4.10.20.1 The constraint validation API

element.willValidate

Returns true if the element will be validated when the form is submitted; false otherwise.

element.setCustomValidity(message)

✔MDN

HTMLInputElement/setCustomValidity

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS4+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Sets a custom error, so that the element would fail to validate. The given message is the message to be shown to the user when reporting the problem to the user.

If the argument is the empty string, clears the custom error.

element.validity.valueMissing

Returns true if the element has no value but is a required field; false otherwise.

element.validity.typeMismatch

✔MDN

ValidityState/typeMismatch

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS5+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Returns true if the element's value is not in the correct syntax; false otherwise.

element.validity.patternMismatch

✔MDN

ValidityState/patternMismatch

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS5+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Returns true if the element's value doesn't match the provided pattern; false otherwise.

element.validity.tooLong

Returns true if the element's value is longer than the provided maximum length; false otherwise.

element.validity.tooShort

Returns true if the element's value, if it is not the empty string, is shorter than the provided minimum length; false otherwise.

element.validity.rangeUnderflow

✔MDN

ValidityState/rangeUnderflow

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS5+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Returns true if the element's value is lower than the provided minimum; false otherwise.

element.validity.rangeOverflow

✔MDN

ValidityState/rangeOverflow

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS5+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Returns true if the element's value is higher than the provided maximum; false otherwise.

element.validity.stepMismatch

✔MDN

ValidityState/stepMismatch

Support in all current engines.

Firefox4+Safari5+Chrome4+

---

Opera12.1+Edge79+

---

Edge (Legacy)12+Internet Explorer10+

---

Firefox Android?Safari iOS5+Chrome Android?WebView Android37+Samsung Internet?Opera Android12.1+

Returns true if the element's value doesn't fit the rules given by the step attribute; false otherwise.

element.validity.badInput

Returns true if the user has provided input in the user interface that the user agent is unable to convert to a value; false otherwise.

element.validity.customError

Returns true if the element has a custom error; false otherwise.

element.validity.valid

Returns true if the element's value has no validity problems; false otherwise.

valid = element.checkValidity()

Returns true if the element's value has no validity problems; false otherwise. Fires an invalid event at the element in the latter case.

valid = element.reportValidity()

Returns true if the element's value has no validity problems; otherwise, returns false, fires an invalid event at the element, and (if the event isn't canceled) reports the problem to the user.

element.validationMessage

Returns the error message that would be shown to the user if the element was to be checked for validity.

<label>Feeling: <input name=f type="text" oninput="check(this)"></label>
<script>
 function check(input) {
   if (input.value == "good" ||
       input.value == "fine" ||
       input.value == "tired") {
     input.setCustomValidity('"' + input.value + '" is not a feeling.');
   } else {
     // input is fine -- reset the error message
     input.setCustomValidity('');
   }
 }
</script>

4.10.20.2 Security

Servers should not rely on client-side validation. Client-side validation can be intentionally bypassed by hostile users, and unintentionally bypassed by users of older user agents or automated tools that do not implement these features. The constraint validation features are only intended to improve the user experience, not to provide any kind of security mechanism.

4.10.21 Form submission

When a form is submitted, the data in the form is converted into the structure specified by the enctype, and then sent to the destination specified by the action using the given method.

For example, take the following form:

<form action="/find.cgi" method=get>
 <input type=text name=t>
 <input type=search name=q>
 <input type=submit>
</form>

If the user types in "cats" in the first field and "fur" in the second, and then hits the submit button, then the user agent will load /find.cgi?t=cats&q=fur.

On the other hand, consider this form:

<form action="/find.cgi" method=post enctype="multipart/form-data">
 <input type=text name=t>
 <input type=search name=q>
 <input type=submit>
</form>

Given the same user input, the result on submission is quite different: the user agent instead does an HTTP POST to the given URL, with as the entity body something like the following text:

------kYFrd4jNJEgCervE
Content-Disposition: form-data; name="t"

cats
------kYFrd4jNJEgCervE
Content-Disposition: form-data; name="q"

fur
------kYFrd4jNJEgCervE--

4.10.21.1 URL-encoded form data

See URL for details on application/x-www-form-urlencoded. [URL]

4.10.21.2 Multipart form data

For details on how to interpret multipart/form-data payloads, see RFC 7578. [RFC7578]

4.10.21.3 Plain text form data

Payloads using the text/plain format are intended to be human readable. They are not reliably interpretable by computer, as the format is ambiguous (for example, there is no way to distinguish a literal newline in a value from the newline at the end of the value).

4.10.21.4 The SubmitEvent interface

event.submitter

Returns the element representing the submit button that triggered the form submission, or null if the submission was not triggered by a button.

4.10.21.5 The FormDataEvent interface

event.formData

Returns a FormData object representing names and values of elements associated to the target form. Operations on the FormData object will affect form data to be submitted.