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
          1. 4.10.18.6.1 Autofocusing a form control: the autofocus attribute
        7. 4.10.18.7 Autofill
          1. 4.10.18.7.1 Autofilling form controls: the autocomplete attribute
          2. 4.10.18.7.2 Processing model
      3. 4.10.19 APIs for the text control selections
      4. 4.10.20 Constraints
        1. 4.10.20.1 Definitions
        2. 4.10.20.2 Constraint validation
        3. 4.10.20.3 The constraint validation API
        4. 4.10.20.4 Security
      5. 4.10.21 Form submission
        1. 4.10.21.1 Introduction
        2. 4.10.21.2 Implicit submission
        3. 4.10.21.3 Form submission algorithm
        4. 4.10.21.4 Constructing the entry list
        5. 4.10.21.5 Selecting a form submission encoding
        6. 4.10.21.6 URL-encoded form data
        7. 4.10.21.7 Multipart form data
        8. 4.10.21.8 Plain text form data
      6. 4.10.22 Resetting a form

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.

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 nearest ancestor form element (as described below), but, if it is listed, may have a form attribute specified to override this.

Support: form-attributeChrome for Android 70+Chrome 10+iOS Safari 5.0+UC Browser for Android 11.8+Firefox 4+IE NoneOpera Mini all+Safari 5.1+Edge 16+Opera 9.5+Samsung Internet 4+Android Browser 3+

Source: caniuse.com

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 form-associated element or one of its ancestors is inserted, then:

  1. If the form-associated element's parser inserted flag is set, then return.

  2. Reset the form owner of the form-associated element.

When a form-associated element or one of its ancestors is removed, then:

  1. If the form-associated element has a form owner and the form-associated element and its form owner are no longer in the same tree, then reset the form owner of the form-associated element.

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, 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 element, it must run the following steps:

  1. Unset element's parser inserted flag.

  2. If all of the following conditions are true

    then do nothing, and return.

  3. Set element's form owner to null.

  4. If element is listed, has a form content attribute, and is connected, then:

    1. If the first element in element's tree, in tree order, to have an ID that is case-sensitively equal to element's form content attribute's value, is a form element, then associate the element with that form element.

  5. 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 . form

Returns the element's form owner.

Returns null if there isn't one.

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

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

The name IDL attribute must reflect the name content attribute.

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.

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.

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
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 JavaScript string 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 JavaScript string 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 JavaScript string 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).

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 JavaScript string 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 JavaScript string 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>
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 conditions are met:

  1. The element is a button, input, select, or textarea element, and the disabled attribute is specified on this element (regardless of its value).
  2. 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.

Constraint validation: If an element is disabled, it is barred from constraint validation.

The disabled IDL attribute must reflect the disabled content attribute.

4.10.18.6 Form submission

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

Support: form-submit-attributesChrome for Android 70+Chrome 15+iOS Safari 5.0+UC Browser for Android 11.8+Firefox 4+IE 10+Opera Mini all+Safari 5.1+Edge 12+Opera 10.6+Samsung Internet 4+Android Browser 4+

Source: caniuse.com

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 invalid value default for these attributes is the GET state. The missing value default for the method attribute is also the GET state. (There is no missing value default or invalid value default for the formmethod attribute.)

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>

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

The invalid value default for these attributes is the application/x-www-form-urlencoded state. The missing value default for the enctype attribute is also the application/x-www-form-urlencoded state. (There is no missing value default for the formenctype attribute.)

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 browsing context 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.

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>

The action IDL attribute must reflect the content attribute of the same name, except that on getting, when the content attribute is missing or its value is the empty string, the element's node document's URL must be returned instead. The target IDL attribute must reflect the content attribute of the same name. 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 noValidate IDL attribute must reflect the novalidate content attribute. The formAction IDL attribute must reflect the formaction content attribute, except that on getting, when the content attribute is missing or its value is the empty string, the element's node document's URL must be returned instead. 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. The formNoValidate IDL attribute must reflect the formnovalidate content attribute. The formTarget IDL attribute must reflect the formtarget content attribute.

4.10.18.6.1 Autofocusing a form control: the autofocus attribute

Support: autofocusChrome for Android 70+Chrome 5+iOS Safari NoneUC Browser for Android NoneFirefox 4+IE 10+Opera Mini NoneSafari 5+Edge 12+Opera 9.5+Samsung Internet 4+Android Browser 3+

Source: caniuse.com

The autofocus content attribute allows the author to indicate that a control is to be focused as soon as the page is loaded or as soon as the dialog within which it finds itself is shown, allowing the user to just start typing without having to manually focus the main control.

The autofocus attribute is a boolean attribute.

An element's nearest ancestor autofocus scoping root element is the element itself if the element is a dialog element, or else is the element's nearest ancestor dialog element, if any, or else is the element's last inclusive ancestor element.

There must not be two elements with the same nearest ancestor autofocus scoping root element that both have the autofocus attribute specified.

When an element with the autofocus attribute specified is inserted into a document, queue a task on the user interaction task source to run the following steps:

  1. If the user has indicated (for example, by starting to type in a form control) that they do not wish focus to be changed, then optionally return.

  2. Let target be the element's node document.

  3. If target has no browsing context, then return.

  4. If target's browsing context has no top-level browsing context (e.g., it is a nested browsing context with no parent browsing context), then return.

  5. If target's active sandboxing flag set has the sandboxed automatic features browsing context flag, then return.

  6. If target's origin is not the same as the origin of the node document of the currently focused element in target's top-level browsing context, then return.

  7. If target's origin is not the same as the origin of the active document of target's top-level browsing context, then return.

  8. If the user agent has already reached the last step of this list of steps in response to an element being inserted into a Document whose top-level browsing context's active document is the same as target's top-level browsing context's active document, then return.

  9. Run the focusing steps for the element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention.

This handles the automatic focusing during document load. The show() and showModal() methods of dialog elements also processes the autofocus attribute.

Focusing the control does not imply that the user agent has to focus the browser window if it has lost focus.

The autofocus IDL attribute must reflect the content attribute of the same name.

In the following snippet, the text control would be focused when the document was loaded.

<input maxlength="256" name="q" value="" autofocus>
<input type="submit" value="Search">
4.10.18.7 Autofill

Support: input-autocomplete-onoffChrome for Android 70+Chrome (limited) 27+iOS Safari 5.0+UC Browser for Android 11.8+Firefox (limited) 30+IE (limited) 11+Opera Mini all+Safari (limited) 7+Edge (limited) 12+Opera 9+Samsung Internet 4+Android Browser 2.1+

Source: caniuse.com

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:

  3. Either of the following two options:

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.

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 Text
"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
"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" E-mail address Valid e-mail address timbl@w3.org E-mail
"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:

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
E-mail
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 E-mail 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.18.7.2 Processing model

Each input element to which the autocomplete attribute applies, each select element, and each textarea element, has an autofill hint set, an autofill scope, an autofill field name, and an IDL-exposed autofill value.

The autofill field name specifies the specific kind of data expected in the field, e.g. "street-address" or "cc-exp".

The autofill hint set identifies what address or contact information type the user agent is to look at, e.g. "shipping fax" or "billing".

The autofill scope identifies the group of fields whose information concerns the same subject, and consists of the autofill hint set with, if applicable, the "section-*" prefix, e.g. "billing", "section-parent shipping", or "section-child shipping home".

These values are defined as the result of running the following algorithm:

  1. If the element has no autocomplete attribute, then jump to the step labeled default.

  2. Let tokens be the result of splitting the attribute's value on ASCII whitespace.

  3. If tokens is empty, then jump to the step labeled default.

  4. Let index be the index of the last token in tokens.

  5. If the indexth token in tokens is not an ASCII case-insensitive match for one of the tokens given in the first column of the following table, or if the number of tokens in tokens is greater than the maximum number given in the cell in the second column of that token's row, then jump to the step labeled default. Otherwise, let field be the string given in the cell of the first column of the matching row, and let category be the value of the cell in the third column of that same row.

    Token Maximum number of tokens Category
    "off" 1 Off
    "on" 1 Automatic
    "name" 3 Normal
    "honorific-prefix" 3 Normal
    "given-name" 3 Normal
    "additional-name" 3 Normal
    "family-name" 3 Normal
    "honorific-suffix" 3 Normal
    "nickname" 3 Normal
    "organization-title" 3 Normal
    "username" 3 Normal
    "new-password" 3 Normal
    "current-password" 3 Normal
    "organization" 3 Normal
    "street-address" 3 Normal
    "address-line1" 3 Normal
    "address-line2" 3 Normal
    "address-line3" 3 Normal
    "address-level4" 3 Normal
    "address-level3" 3 Normal
    "address-level2" 3 Normal
    "address-level1" 3 Normal
    "country" 3 Normal
    "country-name" 3 Normal
    "postal-code" 3 Normal
    "cc-name" 3 Normal
    "cc-given-name" 3 Normal
    "cc-additional-name" 3 Normal
    "cc-family-name" 3 Normal
    "cc-number" 3 Normal
    "cc-exp" 3 Normal
    "cc-exp-month" 3 Normal
    "cc-exp-year" 3 Normal
    "cc-csc" 3 Normal
    "cc-type" 3 Normal
    "transaction-currency" 3 Normal
    "transaction-amount" 3 Normal
    "language" 3 Normal
    "bday" 3 Normal
    "bday-day" 3 Normal
    "bday-month" 3 Normal
    "bday-year" 3 Normal
    "sex" 3 Normal
    "url" 3 Normal
    "photo" 3 Normal
    "tel" 4 Contact
    "tel-country-code" 4 Contact
    "tel-national" 4 Contact
    "tel-area-code" 4 Contact
    "tel-local" 4 Contact
    "tel-local-prefix" 4 Contact
    "tel-local-suffix" 4 Contact
    "tel-extension" 4 Contact
    "email" 4 Contact
    "impp" 4 Contact
  6. If category is Off or Automatic but the element's autocomplete attribute is wearing the autofill anchor mantle, then jump to the step labeled default.

  7. If category is Off, let the element's autofill field name be the string "off", let its autofill hint set be empty, and let its IDL-exposed autofill value be the string "off". Then, return.

  8. If category is Automatic, let the element's autofill field name be the string "on", let its autofill hint set be empty, and let its IDL-exposed autofill value be the string "on". Then, return.

  9. Let scope tokens be an empty list.

  10. Let hint tokens be an empty set.

  11. Let IDL value have the same value as field.

  12. If the indexth token in tokens is the first entry, then skip to the step labeled done.

  13. Decrement index by one.

  14. If category is Contact and the indexth token in tokens is an ASCII case-insensitive match for one of the strings in the following list, then run the substeps that follow:

    The substeps are:

    1. Let contact be the matching string from the list above.

    2. Insert contact at the start of scope tokens.

    3. Add contact to hint tokens.

    4. Let IDL value be the concatenation of contact, a U+0020 SPACE character, and the previous value of IDL value (which at this point will always be field).

    5. If the indexth entry in tokens is the first entry, then skip to the step labeled done.

    6. Decrement index by one.

  15. If the indexth token in tokens is an ASCII case-insensitive match for one of the strings in the following list, then run the substeps that follow:

    The substeps are:

    1. Let mode be the matching string from the list above.

    2. Insert mode at the start of scope tokens.

    3. Add mode to hint tokens.

    4. Let IDL value be the concatenation of mode, a U+0020 SPACE character, and the previous value of IDL value (which at this point will either be field or the concatenation of contact, a space, and field).

    5. If the indexth entry in tokens is the first entry, then skip to the step labeled done.

    6. Decrement index by one.

  16. If the indexth entry in tokens is not the first entry, then jump to the step labeled default.

  17. If the first eight characters of the indexth token in tokens are not an ASCII case-insensitive match for the string "section-", then jump to the step labeled default.

  18. Let section be the indexth token in tokens, converted to ASCII lowercase.

  19. Insert section at the start of scope tokens.

  20. Let IDL value be the concatenation of section, a U+0020 SPACE character, and the previous value of IDL value.

  21. Done: Let the element's autofill hint set be hint tokens.

  22. Let the element's autofill scope be scope tokens.

  23. Let the element's autofill field name be field.

  24. Let the element's IDL-exposed autofill value be IDL value.

  25. Return.

  26. Default: Let the element's IDL-exposed autofill value be the empty string, and its autofill hint set and autofill scope be empty.

  27. If the element's autocomplete attribute is wearing the autofill anchor mantle, then let the element's autofill field name be the empty string and return.

  28. Let form be the element's form owner, if any, or null otherwise.

  29. If form is not null and form's autocomplete attribute is in the off state, then let the element's autofill field name be "off".

    Otherwise, let the element's autofill field name be "on".


For the purposes of autofill, a control's data depends on the kind of control:

An input element with its type attribute in the E-mail state and with the multiple attribute specified
The element's values.
Any other input element
A textarea element
The element's value.
A select element with its multiple attribute specified
The option elements in the select element's list of options that have their selectedness set to true.
Any other select element
The option element in the select element's list of options that has its selectedness set to true.

How to process the autofill hint set, autofill scope, and autofill field name depends on the mantle that the autocomplete attribute is wearing.

When wearing the autofill expectation mantle...

When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user.

In addition, when an element's autofill field name is "off", values are reset when traversing the history.

Banks frequently do not want UAs to prefill login information:

<p><label>Account: <input type="text" name="ac" autocomplete="off"></label></p>
<p><label>PIN: <input type="password" name="pin" autocomplete="off"></label></p>

When an element's autofill field name is not "off", the user agent may store the control's data, and may offer previously stored values to the user.

For example, suppose a user visits a page with this control:

<select name="country">
 <option>Afghanistan
 <option>Albania
 <option>Algeria
 <option>Andorra
 <option>Angola
 <option>Antigua and Barbuda
 <option>Argentina
 <option>Armenia
 <!-- ... -->
 <option>Yemen
 <option>Zambia
 <option>Zimbabwe
</select>

This might render as follows:

A drop-down control with a long alphabetical list of countries.

Suppose that on the first visit to this page, the user selects "Zambia". On the second visit, the user agent could duplicate the entry for Zambia at the top of the list, so that the interface instead looks like this:

The same drop-down control with the alphabetical list of countries, but with Zambia as an entry at the top.

When the autofill field name is "on", the user agent should attempt to use heuristics to determine the most appropriate values to offer the user, e.g. based on the element's name value, the position of the element in its tree, what other fields exist in the form, and so forth.

When the autofill field name is one of the names of the autofill fields described above, the user agent should provide suggestions that match the meaning of the field name as given in the table earlier in this section. The autofill hint set should be used to select amongst multiple possible suggestions.

For example, if a user once entered one address into fields that used the "shipping" keyword, and another address into fields that used the "billing" keyword, then in subsequent forms only the first address would be suggested for form controls whose autofill hint set contains the keyword "shipping". Both addresses might be suggested, however, for address-related form controls whose autofill hint set does not contain either keyword.

When wearing the autofill anchor mantle...

When the autofill field name is not the empty string, then the user agent must act as if the user had specified the control's data for the given autofill hint set, autofill scope, and autofill field name combination.

When the user agent autofills form controls, elements with the same form owner and the same autofill scope must use data relating to the same person, address, payment instrument, and contact details. When a user agent autofills "country" and "country-name" fields with the same form owner and autofill scope, and the user agent has a value for the country" field(s), then the "country-name" field(s) must be filled using a human-readable name for the same country. When a user agent fills in multiple fields at once, all fields with the same autofill field name, form owner and autofill scope must be filled with the same value.

Suppose a user agent knows of two phone numbers, +1 555 123 1234 and +1 555 666 7777. It would not be conforming for the user agent to fill a field with autocomplete="shipping tel-local-prefix" with the value "123" and another field in the same form with autocomplete="shipping tel-local-suffix" with the value "7777". The only valid prefilled values given the aforementioned information would be "123" and "1234", or "666" and "7777", respectively.

Similarly, if a form for some reason contained both a "cc-exp" field and a "cc-exp-month" field, and the user agent prefilled the form, then the month component of the former would have to match the latter.

This requirement interacts with the autofill anchor mantle also. Consider the following markup snippet:

<form>
 <input type=hidden autocomplete="nickname" value="TreePlate">
 <input type=text autocomplete="nickname">
</form>

The only value that a conforming user agent could suggest in the text control is "TreePlate", the value given by the hidden input element.

The "section-*" tokens in the autofill scope are opaque; user agents must not attempt to derive meaning from the precise values of these tokens.

For example, it would not be conforming if the user agent decided that it should offer the address it knows to be the user's daughter's address for "section-child" and the addresses it knows to be the user's spouses' addresses for "section-spouse".

The autocompletion mechanism must be implemented by the user agent acting as if the user had modified the control's data, and must be done at a time where the element is mutable (e.g. just after the element has been inserted into the document, or when the user agent stops parsing). User agents must only prefill controls using values that the user could have entered.

For example, if a select element only has option elements with values "Steve" and "Rebecca", "Jay", and "Bob", and has an autofill field name "given-name", but the user agent's only idea for what to prefill the field with is "Evan", then the user agent cannot prefill the field. It would not be conforming to somehow set the select element to the value "Evan", since the user could not have done so themselves.

A user agent prefilling a form control must not discriminate between form controls that are in a document tree and those that are connected; that is, it is not conforming to make the decision on whether or not to autofill based on whether the element's root is a shadow root versus a Document.

A user agent prefilling a form control's value must not cause that control to suffer from a type mismatch, suffer from being too long, suffer from being too short, suffer from an underflow, suffer from an overflow, or suffer from a step mismatch. A user agent prefilling a form control's value must not cause that control to suffer from a pattern mismatch either. Where possible given the control's constraints, user agents must use the format given as canonical in the aforementioned table. Where it's not possible for the canonical format to be used, user agents should use heuristics to attempt to convert values so that they can be used.

For example, if the user agent knows that the user's middle name is "Ines", and attempts to prefill a form control that looks like this:

<input name=middle-initial maxlength=1 autocomplete="additional-name">

...then the user agent could convert "Ines" to "I" and prefill it that way.

A more elaborate example would be with month values. If the user agent knows that the user's birthday is the 27th of July 2012, then it might try to prefill all of the following controls with slightly different values, all driven from this information:

<input name=b type=month autocomplete="bday">
2012-07 The day is dropped since the Month state only accepts a month/year combination. (Note that this example is non-conforming, because the autofill field name bday is not allowed with the Month state.)
<select name=c autocomplete="bday">
 <option>Jan
 <option>Feb
 ...
 <option>Jul
 <option>Aug
 ...
</select>
July The user agent picks the month from the listed options, either by noticing there are twelve options and picking the 7th, or by recognizing that one of the strings (three characters "Jul" followed by a newline and a space) is a close match for the name of the month (July) in one of the user agent's supported languages, or through some other similar mechanism.
<input name=a type=number min=1 max=12 autocomplete="bday-month">
7 User agent converts "July" to a month number in the range 1..12, like the field.
<input name=a type=number min=0 max=11 autocomplete="bday-month">
6 User agent converts "July" to a month number in the range 0..11, like the field.
<input name=a type=number min=1 max=11 autocomplete="bday-month">
User agent doesn't fill in the field, since it can't make a good guess as to what the form expects.

A user agent may allow the user to override an element's autofill field name, e.g. to change it from "off" to "on" to allow values to be remembered and prefilled despite the page author's objections, or to always "off", never remembering values.

More specifically, user agents may in particular consider replacing the autofill field name of form controls that match the description given in the first column of the following table, when their autofill field name is either "on" or "off", with the value given in the second cell of that row. If this table is used, the replacements must be done in tree order, since all but the first row references the autofill field name of earlier elements. When the descriptions below refer to form controls being preceded or followed by others, they mean in the list of listed elements that share the same form owner.

Form control New autofill field name
an input element whose type attribute is in the Text state that is followed by an input element whose type attribute is in the Password state "username"
an input element whose type attribute is in the Password state that is preceded by an input element whose autofill field name is "username" "current-password"
an input element whose type attribute is in the Password state that is preceded by an input element whose autofill field name is "current-password" "new-password"
an input element whose type attribute is in the Password state that is preceded by an input element whose autofill field name is "new-password" "new-password"

The autocomplete IDL attribute, on getting, must return the element's IDL-exposed autofill value, and on setting, must reflect the content attribute of the same name.

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

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.

All input elements to which these APIs apply, and all textarea elements, have either a selection or a text entry cursor position at all times (even for elements that are not being rendered). The initial state must consist of a text entry cursor at the beginning of the control.

For input elements, these APIs must operate on the element's value. For textarea elements, these APIs must operate on the element's API value. In the below algorithms, we call the value string being operated on the relevant value.

The use of API value instead of raw value for textarea elements means that U+000D (CR) characters are normalized away. For example,

<textarea id="demo"></textarea>
<script>
 demo.value = "A\r\nB";
 demo.setRangeText("replaced", 0, 2);
 assert(demo.value === "replacedB");
</script>

If we had operated on the raw value of "A\r\nB", then we would have replaced the characters "A\r", ending up with a result of "replaced\nB". But since we used the API value of "A\nB", we replaced the characters "A\n", giving "replacedB".

Whenever the relevant value changes for an element to which these APIs apply, run these steps:

  1. If the element has a selection:

    1. If the start of the selection is now past the end of the relevant value, set it to the end of the relevant value.

    2. If the end of the selection is now past the end of the relevant value, set it to the end of the relevant value.

    3. If the user agent does not support empty selection, and both the start and end of the selection are now pointing to the end of the relevant value, then instead set the element's text entry cursor position to the end of the relevant value, removing any selection.

  2. Otherwise, the element must have a text entry cursor position position. If it is now past the end of the relevant value, set it to the end of the relevant value.

In some cases where the relevant value changes, other parts of the specification will also modify the text entry cursor position, beyond just the clamping steps above. For example, see the value setter for textarea.

Characters with no visible rendering, such as U+200D ZERO WIDTH JOINER, still count as characters. Thus, for instance, the selection can include just an invisible character, and the text insertion cursor can be placed to one side or another of such a character.

Where possible, user interface features for changing the text selection in input and textarea elements must be implemented using the set the selection range algorithm so that, e.g., all the same events fire.

The selections of input and textarea elements have a selection direction, which is either "forward", "backward", or "none". This direction is set when the user manipulates the selection. The exact meaning of the selection direction depends on the platform. To set the selection direction of an element to a given direction, update the element's selection direction to the given direction, unless the direction is "none" and the platform does not support that direction; in that case, update the element's selection direction to "forward".

On Windows, the direction indicates the position of the caret relative to the selection: a "forward" selection has the caret at the end of the selection and a "backward" selection has the caret at the start of the selection. Windows has no "none" direction.

On Mac, the direction indicates which end of the selection is affected when the user adjusts the size of the selection using the arrow keys with the Shift modifier: the "forward" direction means the end of the selection is modified, and the "backward" direction means the start of the selection is modified. The "none" direction is the default on Mac, it indicates that no particular direction has yet been selected. The user sets the direction implicitly when first adjusting the selection, based on which directional arrow key was used.

The select() method, when invoked, must run the following steps:

  1. If this element is an input element, and either select() does not apply to this element or the corresponding control has no selectable text, return.

    For instance, in a user agent where <input type=color> is rendered as a color well with a picker, as opposed to a text control accepting a hexadecimal color code, there would be no selectable text, and thus calls to the method are ignored.

  2. Set the selection range with 0 and infinity.

The selectionStart attribute's getter must run the following steps:

  1. If this element is an input element, and selectionStart does not apply to this element, return null.

  2. If there is no selection, return the offset (in logical order) within the relevant value to the character that immediately follows the text entry cursor.

  3. Return the offset (in logical order) within the relevant value to the character that immediately follows the start of the selection.

The selectionStart attribute's setter must run the following steps:

  1. If this element is an input element, and selectionStart does not apply to this element, throw an "InvalidStateError" DOMException.

  2. Let end be the value of this element's selectionEnd attribute.

  3. If end is less than the given value, set end to the given value.

  4. Set the selection range with the given value, end, and the value of this element's selectionDirection attribute.

The selectionEnd attribute's getter must run the following steps:

  1. If this element is an input element, and selectionEnd does not apply to this element, return null.

  2. If there is no selection, return the offset (in logical order) within the relevant value to the character that immediately follows the text entry cursor.

  3. Return the offset (in logical order) within the relevant value to the character that immediately follows the end of the selection.

The selectionEnd attribute's setter must run the following steps:

  1. If this element is an input element, and selectionEnd does not apply to this element, throw an "InvalidStateError" DOMException.

  2. Set the selection range with the value of this element's selectionStart attribute, the given value, and the value of this element's selectionDirection attribute.

The selectionDirection attribute's getter must run the following steps:

  1. If this element is an input element, and selectionDirection does not apply to this element, return null.

  2. Return this element's selection direction.

The selectionDirection attribute's setter must run the following steps:

  1. If this element is an input element, and selectionDirection does not apply to this element, throw an "InvalidStateError" DOMException.

  2. Set the selection range with the value of this element's selectionStart attribute, the value of this element's selectionEnd attribute, and the given value.

The setSelectionRange(start, end, direction) method, when invoked, must run the following steps:

Support: input-selectionChrome for Android 70+Chrome 4+iOS Safari 4.0+UC Browser for Android 11.8+Firefox 2+IE 9+Opera Mini NoneSafari 4+Edge 12+Opera 10.6+Samsung Internet 4+Android Browser 2.1+

Source: caniuse.com

  1. If this element is an input element, and setSelectionRange() does not apply to this element, throw an "InvalidStateError" DOMException.

  2. Set the selection range with start, end, and direction.

To set the selection range with an integer or null start, an integer or null or the special value infinity end, and optionally a string direction, run the following steps:

  1. If start is null, let start be zero.

  2. If end is null, let end be zero.

  3. Set the selection of the text control to the sequence of characters within the relevant value starting with the character at the startth position (in logical order) and ending with the character at the (end-1)th position. Arguments greater than the length of the relevant value of the text control (including the special value infinity) must be treated as pointing at the end of the text control. If end is less than or equal to start then the start of the selection and the end of the selection must both be placed immediately before the character with offset end. In UAs where there is no concept of an empty selection, this must set the cursor to be just before the character with offset end.

  4. If direction is not a case-sensitive match for either the string "backward" or "forward", or if the direction argument was omitted, set direction to "none".

  5. Set the selection direction of the text control to direction.

  6. If the previous steps caused the selection of the text control to be modified (in either extent or direction), then queue a task, using the user interaction task source, to fire an event named select at the element, with the bubbles attribute initialized to true.

The setRangeText(replacement, start, end, selectMode) method, when invoked, must run the following steps:

  1. If this element is an input element, and setRangeText() does not apply to this element, throw an "InvalidStateError" DOMException.

  2. Set this element's dirty value flag to true.

  3. If the method has only one argument, then let start and end have the values of the selectionStart attribute and the selectionEnd attribute respectively.

    Otherwise, let start, end have the values of the second and third arguments respectively.

  4. If start is greater than end, then throw an "IndexSizeError" DOMException.

  5. If start is greater than the length of the relevant value of the text control, then set it to the length of the relevant value of the text control.

  6. If end is greater than the length of the relevant value of the text control, then set it to the length of the relevant value of the text control.

  7. Let selection start be the current value of the selectionStart attribute.

  8. Let selection end be the current value of the selectionEnd attribute.

  9. If start is less than end, delete the sequence of characters within the element's relevant value starting with the character at the startth position (in logical order) and ending with the character at the (end-1)th position.

  10. Insert the value of the first argument into the text of the relevant value of the text control, immediately before the startth character.

  11. Let new length be the length of the value of the first argument.

  12. Let new end be the sum of start and new length.

  13. Run the appropriate set of substeps from the following list:

    If the fourth argument's value is "select"

    Let selection start be start.

    Let selection end be new end.

    If the fourth argument's value is "start"

    Let selection start and selection end be start.

    If the fourth argument's value is "end"

    Let selection start and selection end be new end.

    If the fourth argument's value is "preserve"
    If the method has only one argument
    1. Let old length be end minus start.

    2. Let delta be new length minus old length.

    3. If selection start is greater than end, then increment it by delta. (If delta is negative, i.e. the new text is shorter than the old text, then this will decrease the value of selection start.)

      Otherwise: if selection start is greater than start, then set it to start. (This snaps the start of the selection to the start of the new text if it was in the middle of the text that it replaced.)

    4. If selection end is greater than end, then increment it by delta in the same way.

      Otherwise: if selection end is greater than start, then set it to new end. (This snaps the end of the selection to the end of the new text if it was in the middle of the text that it replaced.)

  14. Set the selection range with selection start and selection end.

The setRangeText() method uses the following enumeration:

enum SelectionMode {
  "select",
  "start",
  "end",
  "preserve" // default
};

To obtain the currently selected text, the following JavaScript suffices:

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

...where control is the input or textarea element.

To add some text at the start of a text control, while maintaining the text selection, the three attributes must be preserved:

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

...where control is the input or textarea element.

4.10.20 Constraints

4.10.20.1 Definitions

A submittable element is a candidate for constraint validation except when a condition has barred the element from constraint validation. (For example, an element is barred from constraint validation if it is an object element.)

An element can have a custom validity error message defined. Initially, an element must have its custom validity error message set to the empty string. When its value is not the empty string, the element is suffering from a custom error. It can be set using the setCustomValidity() method. The user agent should use the custom validity error message when alerting the user to the problem with the control.

An element can be constrained in various ways. The following is the list of validity states that a form control can be in, making the control invalid for the purposes of constraint validation. (The definitions below are non-normative; other parts of this specification define more precisely when each state applies or does not.)

Suffering from being missing

When a control has no value but has a required attribute (input required, textarea required); or, more complicated rules for select elements and controls in radio button groups, as specified in their sections.

Suffering from a type mismatch

When a control that allows arbitrary user input has a value that is not in the correct syntax (E-mail, URL).

Suffering from a pattern mismatch

When a control has a value that doesn't satisfy the pattern attribute.

Suffering from being too long

When a control has a value that is too long for the form control maxlength attribute (input maxlength, textarea maxlength).

Suffering from being too short

When a control has a value that is too short for the form control minlength attribute (input minlength, textarea minlength).

Suffering from an underflow

When a control has a value that is not the empty string and is too low for the min attribute.

Suffering from an overflow

When a control has a value that is not the empty string and is too high for the max attribute.

Suffering from a step mismatch

When a control has a value that doesn't fit the rules given by the step attribute.

Suffering from bad input

When a control has incomplete input and the user agent does not think the user ought to be able to submit the form in its current state.

Suffering from a custom error

When a control's custom validity error message (as set by the element's setCustomValidity() method) is not the empty string.

An element can still suffer from these states even when the element is disabled; thus these states can be represented in the DOM even if validating the form during submission wouldn't indicate a problem to the user.

An element satisfies its constraints if it is not suffering from any of the above validity states.

4.10.20.2 Constraint validation

When the user agent is required to statically validate the constraints of form element form, it must run the following steps, which return either a positive result (all the controls in the form are valid) or a negative result (there are invalid controls) along with a (possibly empty) list of elements that are invalid and for which no script has claimed responsibility:

  1. Let controls be a list of all the submittable elements whose form owner is form, in tree order.

  2. Let invalid controls be an initially empty list of elements.

  3. For each element field in controls, in tree order:

    1. If field is not a candidate for constraint validation, then move on to the next element.

    2. Otherwise, if field satisfies its constraints, then move on to the next element.

    3. Otherwise, add field to invalid controls.

  4. If invalid controls is empty, then return a positive result.

  5. Let unhandled invalid controls be an initially empty list of elements.

  6. For each element field in invalid controls, if any, in tree order:

    1. Let notCanceled be the result of firing an event named invalid at field, with the cancelable attribute initialized to true.

    2. If notCanceled is true, then add field to unhandled invalid controls.

  7. Return a negative result with the list of elements in the unhandled invalid controls list.

If a user agent is to interactively validate the constraints of form element form, then the user agent must run the following steps:

  1. Statically validate the constraints of form, and let unhandled invalid controls be the list of elements returned if the result was negative.

  2. If the result was positive, then return that result.

  3. Report the problems with the constraints of at least one of the elements given in unhandled invalid controls to the user. User agents may focus one of those elements in the process, by running the focusing steps for that element, and may change the scrolling position of the document, or perform some other action that brings the element to the user's attention. User agents may report more than one constraint violation. User agents may coalesce related constraint violation reports if appropriate (e.g. if multiple radio buttons in a group are marked as required, only one error need be reported). If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error.

  4. Return a negative result.

4.10.20.3 The constraint validation API

Support: constraint-validationChrome for Android 70+Chrome 40+iOS Safari 10.0+UC Browser for Android 11.8+Firefox 51+IE (limited) 10+Opera Mini NoneSafari 10+Edge 17+Opera 27+Samsung Internet 4+Android Browser 67+

Source: caniuse.com

element . willValidate

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

element . setCustomValidity(message)

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

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

element . validity . patternMismatch

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

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

element . validity . rangeOverflow

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

element . validity . stepMismatch

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.

The willValidate attribute's getter must return true, if this element is a candidate for constraint validation, and false otherwise (i.e., false if any conditions are barring it from constraint validation).

The setCustomValidity(message) method, when invoked, must set the custom validity error message to message.

In the following example, a script checks the value of a form control each time it is edited, and whenever it is not a valid value, uses the setCustomValidity() method to set an appropriate message.

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

The validity attribute's getter must return a ValidityState object that represents the validity states of this element. This object is live.

[Exposed=Window]
interface ValidityState {
  readonly attribute boolean valueMissing;
  readonly attribute boolean typeMismatch;
  readonly attribute boolean patternMismatch;
  readonly attribute boolean tooLong;
  readonly attribute boolean tooShort;
  readonly attribute boolean rangeUnderflow;
  readonly attribute boolean rangeOverflow;
  readonly attribute boolean stepMismatch;
  readonly attribute boolean badInput;
  readonly attribute boolean customError;
  readonly attribute boolean valid;
};

A ValidityState object has the following attributes. On getting, they must return true if the corresponding condition given in the following list is true, and false otherwise.

valueMissing

The control is suffering from being missing.

typeMismatch

The control is suffering from a type mismatch.

patternMismatch

The control is suffering from a pattern mismatch.

tooLong

The control is suffering from being too long.

tooShort

The control is suffering from being too short.

rangeUnderflow

The control is suffering from an underflow.

rangeOverflow

The control is suffering from an overflow.

stepMismatch

The control is suffering from a step mismatch.

badInput

The control is suffering from bad input.

customError

The control is suffering from a custom error.

valid

None of the other conditions are true.

The checkValidity() method, when invoked, must run these steps:

  1. If this element is a candidate for constraint validation and does not satisfy its constraints, then:

    1. Fire an event named invalid at this element, with the cancelable attribute initialized to true (though canceling has no effect).

    2. Return false.

  2. Return true.

The reportValidity() method, when invoked, must run these steps:

  1. If this element is a candidate for constraint validation and does not satisfy its constraints, then:

    1. Let report be the result of firing an event named invalid at this element, with the cancelable attribute initialized to true.

    2. If report is true, then report the problems with the constraints of this element to the user. When reporting the problem with the constraints to the user, the user agent may run the focusing steps for this element, and may change the scrolling position of the document, or perform some other action that brings this element to the user's attention. User agents may report more than one constraint violation, if this element suffers from multiple problems at once. If this element is not being rendered, then the user agent may, instead of notifying the user, report the error for the running script.

    3. Return false.

  2. Return true.

The validationMessage attribute's getter must run these steps:

  1. If this element is not a candidate for constraint validation or if this element satisfies its constraints, then return the empty string.

  2. Return a suitably localized message that the user agent would show the user if this were the only form control with a validity constraint problem. If the user agent would not actually show a textual message in such a situation (e.g., it would show a graphical cue instead), then return a suitably localized message that expresses (one or more of) the validity constraint(s) that the control does not satisfy. If the element is a candidate for constraint validation and is suffering from a custom error, then the custom validity error message should be present in the return value.

4.10.20.4 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

4.10.21.1 Introduction

This section is non-normative.

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

A form element's default button is the first submit button in tree order whose form owner is that form element.

If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text control is focused implicitly submits the form), then doing so for a form, whose default button has activation behavior and is not disabled, must cause the user agent to fire a click event at that default button.

There are pages on the Web that are only usable if there is a way to implicitly submit forms, so user agents are strongly encouraged to support this.

If the form has no submit button, then the implicit submission mechanism must do nothing if the form has more than one field that blocks implicit submission, and must submit the form element from the form element itself otherwise.

For the purpose of the previous paragraph, an element is a field that blocks implicit submission of a form element if it is an input element whose form owner is that form element and whose type attribute is in one of the following states: Text, Search, URL, Telephone, E-mail, Password, Date, Month, Week, Time, Local Date and Time, Number

4.10.21.3 Form submission algorithm

When a form element form is submitted from an element submitter (typically a button), optionally with a submitted from submit() method flag set, the user agent must run the following steps:

  1. If form cannot navigate, then return.

  2. Let form document be form's node document.

  3. If form document's active sandboxing flag set has its sandboxed forms browsing context flag set, then return.

  4. Let form browsing context be the browsing context of form document.

  5. If the submitted from submit() method flag is not set, and the submitter element's no-validate state is false, then interactively validate the constraints of form and examine the result: if the result is negative (the constraint validation concluded that there were invalid fields and probably informed the user of this) then fire an event named invalid at the form element and then return.

  6. If the submitted from submit() method flag is not set, then:

    1. Let continue be the result of firing an event named submit at form, with the bubbles attribute initialized to true and the cancelable attribute initialized to true.

    2. If continue is false, then return.

    3. If form cannot navigate, then return.

      Cannot navigate is run again as dispatching the submit event could have changed the outcome.

  7. Let encoding be the result of picking an encoding for the form.

  8. Let entry list be the result of constructing the entry list with form, submitter, and encoding.

  9. Let action be the submitter element's action.

  10. If action is the empty string, let action be the URL of the form document.

  11. Parse the URL action, relative to the submitter element's node document. If this fails, return.

  12. Let parsed action be the resulting URL record.

  13. Let scheme be the scheme of parsed action.

  14. Let enctype be the submitter element's enctype.

  15. Let method be the submitter element's method.

  16. Let target be the submitter element's formtarget attribute value, if the element is a submit button and has such an attribute. Otherwise, let it be the result of getting an element's target given submitter's form owner.

  17. Let target browsing context and replace be the result of applying the rules for choosing a browsing context using target and form browsing context.

  18. If target browsing context is null, then return.

  19. If form document has not yet completely loaded and the submitted from submit() method flag is set, then set replace to true.

  20. If the value of method is dialog then jump to the submit dialog steps.

    Otherwise, select the appropriate row in the table below based on the value of scheme as given by the first cell of each row. Then, select the appropriate cell on that row based on the value of method as given in the first cell of each column. Then, jump to the steps named in that cell and defined below the table.

    GET POST
    http Mutate action URL Submit as entity body
    https Mutate action URL Submit as entity body
    ftp Get action URL Get action URL
    javascript Get action URL Get action URL
    data Mutate action URL Get action URL
    mailto Mail with headers Mail as body

    If scheme is not one of those listed in this table, then the behavior is not defined by this specification. User agents should, in the absence of another specification defining this, act in a manner analogous to that defined in this specification for similar schemes.

    Each form element has a planned navigation, which is either null or a task; when the form is first created, its planned navigation must be set to null. In the behaviors described below, when the user agent is required to plan to navigate to a particular resource destination, it must run the following steps:

    1. If the form has a non-null planned navigation, remove it from its task queue.

    2. Let the form's planned navigation be a new task that consists of running the following steps:

      1. Let the form's planned navigation be null.

      2. Navigate target browsing context to destination. If replace is true, then target browsing context must be navigated with replacement enabled.

      For the purposes of this task, target browsing context and replace are the variables that were set up when the overall form submission algorithm was run, with their values as they stood when this planned navigation was queued.

    3. Queue the task that is the form's new planned navigation.

      The task source for this task is the DOM manipulation task source.

    The behaviors are as follows:

    Mutate action URL

    Let query be the result of running the application/x-www-form-urlencoded serializer with entry list and encoding.

    Set parsed action's query component to query.

    Plan to navigate to parsed action.

    Submit as entity body

    Switch on enctype:

    application/x-www-form-urlencoded

    Let body be the result of running the application/x-www-form-urlencoded serializer with entry list and encoding.

    Set body to the result of encoding body.

    Let MIME type be "application/x-www-form-urlencoded".

    multipart/form-data

    Let body be the result of running the multipart/form-data encoding algorithm with entry list and encoding.

    Let MIME type be the concatenation of the string "multipart/form-data;", a U+0020 SPACE character, the string "boundary=", and the multipart/form-data boundary string generated by the multipart/form-data encoding algorithm.

    text/plain

    Let body be the result of running the text/plain encoding algorithm with entry list.

    Set body to the result of encoding body using encoding.

    Let MIME type be "text/plain".

    Plan to navigate to a new request whose url is parsed action, method is method, header list consists of `Content-Type`/MIME type, and body is body.

    Get action URL

    Plan to navigate to parsed action.

    entry list is discarded.

    Mail with headers

    Let headers be the result of running the application/x-www-form-urlencoded serializer with entry list and encoding.

    Replace occurrences of U+002B PLUS SIGN characters (+) in headers with the string "%20".

    Set parsed action's query to headers.

    Plan to navigate to parsed action.

    Mail as body

    Switch on enctype:

    text/plain

    Let body be the result of running the text/plain encoding algorithm with entry list.

    Set body to the result of concatenating the result of UTF-8 percent encoding each code point in body, using the default encode set. [URL]

    Otherwise

    Let body be the result of running the application/x-www-form-urlencoded serializer with entry list and encoding.

    If parsed action's query is null, then set it to the empty string.

    If parsed action's query is not the empty string, then append a single U+0026 AMPERSAND character (&) to it.

    Append "body=" to parsed action's query.

    Append body to parsed action's query.

    Plan to navigate to parsed action.

    Submit dialog

    Let subject be the nearest ancestor dialog element of form, if any.

    If there isn't one, or if it does not have an open attribute, do nothing. Otherwise, proceed as follows:

    If submitter is an input element whose type attribute is in the Image Button state, then let result be the string formed by concatenating the selected coordinate's x-component, expressed as a base-ten number using ASCII digits, a U+002C COMMA character (,), and the selected coordinate's y-component, expressed in the same way as the x-component.

    Otherwise, if submitter has a value, then let result be that value.

    Otherwise, there is no result.

    Then, close the dialog subject. If there is a result, let that be the return value.

4.10.21.4 Constructing the entry list

The algorithm to construct the entry list given a form, an optional submitter, and an optional encoding, is as follows. If not specified otherwise, submitter is null.

  1. Let controls be a list of all the submittable elements whose form owner is form, in tree order.

  2. Let entry list be a new empty list of entries.

  3. For each element field in controls, in tree order:

    1. If any of the following is true:

      • The field element has a datalist element ancestor.
      • The field element is disabled.
      • The field element is a button but it is not submitter.
      • The field element is an input element whose type attribute is in the Checkbox state and whose checkedness is false.
      • The field element is an input element whose type attribute is in the Radio Button state and whose checkedness is false.
      • The field element is not an input element whose type attribute is in the Image Button state, and either the field element does not have a name attribute specified, or its name attribute's value is the empty string.
      • The field element is an object element that is not using a plugin.

      Then continue.

    2. If the field element is an input element whose type attribute is in the Image Button state, then:

      1. If the field element has a name attribute specified and its value is not the empty string, let name be that value followed by a single U+002E FULL STOP character (.). Otherwise, let name be the empty string.

      2. Let namex be the string consisting of the concatenation of name and a single U+0078 LATIN SMALL LETTER X character (x).

      3. Let namey be the string consisting of the concatenation of name and a single U+0079 LATIN SMALL LETTER Y character (y).

      4. The field element is submitter, and before this algorithm was invoked the user indicated a coordinate. Let x be the x-component of the coordinate selected by the user, and let y be the y-component of the coordinate selected by the user.

      5. Append an entry to entry list with namex and x.

      6. Append an entry to entry list with namey and y.

      7. Continue.

    3. Let name be the value of the field element's name attribute.

    4. If the field element is a select element, then for each option element in the select element's list of options whose selectedness is true and that is not disabled, append an entry to entry list with name and the value of the option element.

    5. Otherwise, if the field element is an input element whose type attribute is in the Checkbox state or the Radio Button state, then:

      1. If the field element has a value attribute specified, then let value be the value of that attribute; otherwise, let value be the string "on".

      2. Append an entry to entry list with name and value.

    6. Otherwise, if the field element is an input element whose type attribute is in the File Upload state, then:

      1. If there are no selected files, then append an entry to entry list with name and a new File object with an empty name, application/octet-stream as type, and an empty body.

      2. Otherwise, for each file in selected files, append an entry to entry list with name and a File object representing the file.

    7. Otherwise, if the field element is an object element: try to obtain a form submission value from the plugin, and if that is successful, append an entry to entry list with name and the returned form submission value.

    8. Otherwise, if the field element is an input element whose type attribute is in the Hidden state and name is "_charset_":

      1. Let charset be the name of encoding if encoding is given, and "UTF-8" otherwise.

      2. Append an entry to entry list with name and charset.

    9. Otherwise, if the field element is a textarea element, append an entry to entry list with name and the value of the field element, and the prevent line break normalization flag set.

      In the case of the value of textarea elements, the line break normalization is already performed during the conversion of the control's raw value into the control's value (which also performs any necessary line wrapping).

    10. Otherwise, append an entry to entry list with name and the value of the field element.

    11. If the element has a dirname attribute, and that attribute's value is not the empty string, then:

      1. Let dirname be the value of the element's dirname attribute.

      2. Let dir be the string "ltr" if the directionality of the element is 'ltr', and "rtl" otherwise (i.e., when the directionality of the element is 'rtl').

      3. Append an entry to entry list with dirname and dir.

      An element can only have a dirname attribute if it is a textarea element or an input element whose type attribute is in either the Text state or the Search state.

  4. Return entry list.

To append an entry to entry list, given name, value, and optional prevent line break normalization flag, run these steps:

  1. For name, replace every occurrence of U+000D (CR) not followed by U+000A (LF), and every occurrence of U+000A (LF) not preceded by U+000D (CR), by a string consisting of a U+000D (CR) and U+000A (LF).

  2. Replace name with the result of converting to a sequence of Unicode scalar values.

  3. If value is not a File object, then:

    1. If the prevent line break normalization flag is unset, then replace every occurrence of U+000D (CR) not followed by U+000A (LF), and every occurrence of U+000A (LF) not preceded by U+000D (CR) in value, by a string consisting of a U+000D (CR) and U+000A (LF).

    2. Replace value with the result of converting to a sequence of Unicode scalar values.

  4. Create an entry with name and value, and append it to entry list.

4.10.21.5 Selecting a form submission encoding

If the user agent is to pick an encoding for a form, it must run the following steps:

  1. Let encoding be the document's character encoding.

  2. If the form element has an accept-charset attribute, set encoding to the return value of running these substeps:

    1. Let input be the value of the form element's accept-charset attribute.

    2. Let candidate encoding labels be the result of splitting input on ASCII whitespace.

    3. Let candidate encodings be an empty list of character encodings.

    4. For each token in candidate encoding labels in turn (in the order in which they were found in input), get an encoding for the token and, if this does not result in failure, append the encoding to candidate encodings.

    5. If candidate encodings is empty, return UTF-8.

    6. Return the first encoding in candidate encodings.

  3. Return the result of getting an output encoding from encoding.

4.10.21.6 URL-encoded form data

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

4.10.21.7 Multipart form data

The multipart/form-data encoding algorithm, given an entry list and encoding, is as follows:

  1. Let result be the empty string.

  2. For each entry in entry list:

    1. For each character in the entry's name and value that cannot be expressed using the selected character encoding, replace the character by a string consisting of a U+0026 AMPERSAND character (&), a U+0023 NUMBER SIGN character (#), one or more ASCII digits representing the code point of the character in base ten, and finally a U+003B (;).

  3. Encode the (now mutated) entry list using the rules described by RFC 7578, Returning Values from Forms: multipart/form-data, and return the resulting byte stream. [RFC7578]

    Each entry in entry list is a field, the name of the entry is the field name and the value of the entry is the field value.

    The order of parts must be the same as the order of fields in entry list. Multiple entries with the same name must be treated as distinct fields.

    The parts of the generated multipart/form-data resource that correspond to non-file fields must not have a `Content-Type` header specified. Their names and values must be encoded using the character encoding selected above.

    File names included in the generated multipart/form-data resource (as part of file fields) must use the character encoding selected above, though the precise name may be approximated if necessary (e.g. newlines could be removed from file names, quotes could be changed to "%22", and characters not expressible in the selected character encoding could be replaced by other characters).

    The boundary used by the user agent in generating the return value of this algorithm is the multipart/form-data boundary string. (This value is used to generate the MIME type of the form submission payload generated by this algorithm.)

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

4.10.21.8 Plain text form data

The text/plain encoding algorithm, given an entry list, is as follows:

  1. Let result be the empty string.

  2. For each entry in entry list:

    1. If the entry's value is a File object, then set its value to the File object's name.

    2. Append the entry's name to result.

    3. Append a single U+003D EQUALS SIGN character (=) to result.

    4. Append the entry's value to result.

    5. Append a U+000D CARRIAGE RETURN (CR) U+000A LINE FEED (LF) character pair to result.

  3. Return result.

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.22 Resetting a form

When a form element form is reset, run these steps:

  1. Let reset be the result of firing an event named reset at form, with the bubbles and cancelable attributes initialized to true.

  2. If reset is true, then invoke the reset algorithm of each resettable element whose form owner is form.

Each resettable element defines its own reset algorithm. Changes made to form controls as part of these algorithms do not count as changes caused by the user (and thus, e.g., do not cause input events to fire).