HTML

The rules in this section are complicated by the fact that although conforming documents will never contain nested form elements, it is quite possible (e.g. using a script that performs DOM manipulation) to generate documents that have such nested elements. They are also complicated by rules in the HTML parser that, for historical reasons, can result in a form-associated element being associated with a form element that is not its ancestor.

When a form-associated element is created, its form owner must be initialized to null (no owner).

When a form-associated element is to be associated with a form, its form owner must be set to that form.

When a form-associated element or one of its ancestors is inserted into a Document, then the user agent must reset the form owner of that form-associated element. The HTML parser overrides this requirement when inserting form controls.

When an element is removed from a Document resulting in a form-associated element and its form owner (if any) no longer being in the same home subtree, then the user agent must reset the form owner of that form-associated element.

When a form-associated element's form attribute is set, changed, or removed, then the user agent must reset the form owner of that element.

When a form-associated element has a form attribute and the ID of any of the elements in the Document changes, then the user agent must reset the form owner of that form-associated element.

When a form-associated element has a form attribute and an element with an ID is inserted into or removed from the Document, then the user agent must reset the form owner of that form-associated element.

When the user agent is to reset the form owner of a form-associated element, it must run the following steps:

1. If the element's form owner is not null, and the element's form content attribute is not present, and the element's form owner is its nearest form element ancestor after the change to the ancestor chain, then do nothing, and abort these steps.

2. Let the element's form owner be null.

3. If the element has a form content attribute and is itself in a Document, then run these substeps:

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

   2. Abort the "reset the form owner" steps.

4. Otherwise, if the form-associated element in question has an ancestor form element, then associate the form-associated element with the nearest such ancestor form element.

5. Otherwise, the element is left unassociated.

...
 <form id="a">
  <div id="b"></div>
 </form>
 <script>
  document.getElementById('b').innerHTML =
     '<table><tr><td><form id="c"><input id="d"></table>' +
     '<input id="e">';
 </script>
...

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.

The name IDL attribute must reflect the name content attribute.

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 code-unit length of the element's 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 value to be set to a value whose code-unit length is greater than the element's maximum allowed value length.

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.

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 document's address 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 document's address 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.

When an element with the autofocus attribute specified is inserted into a document, user agents should run the following steps:

1. Let target be the element's Document.

2. If target has no browsing context, abort these steps.

3. If target's browsing context has no top-level browsing context (e.g. it is a nested browsing context with no parent browsing context), abort these steps.

4. If target's active sandboxing flag set has the sandboxed automatic features browsing context flag, abort these steps.

5. If target's origin is not the same as the origin of the Document of the currently focused element in target's top-level browsing context, abort these steps.

6. If target's origin is not the same as the origin of the active document of target's top-level browsing context, abort these steps.

7. 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, abort these steps.

8. If the user has indicated (for example, by starting to type in a form control) that he does not wish focus to be changed, then optionally abort these steps.

9. Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that 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. The task source for this task is the DOM manipulation task source.

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

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

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

User agents must recognise all the keywords and corresponding states given below, but need not support all of the corresponding states. If a keyword's state is not supported, the user agent must act as if the keyword instead mapped to the given state's fallback state, as defined below. This fallback behaviour is transitive.

For example, if a user agent with a QWERTY keyboard layout does not support text prediction and automatic capitalization, then it could treat the latin-prose keyword in the same way as the verbatim keyword, following the chain Latin Prose → Latin Text → Latin Verbatim.

User agents should use the input modality corresponding to the state of the inputmode attribute when exposing a user interface for editing the value of a form control to which the attribute applies. An input modality corresponding to a state is one designed to fit the description of the state in the table above. This value can change dynamically; user agents should update their interface as the attribute changes state, unless that would go against the user's wishes.

Each input, select, and textarea element has an autofill hint set, an autofill scope, an autofill field name, and an IDL-exposed autofill value whose 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 spaces.

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
   "organization"	3	Normal
   "street-address"	3	Normal
   "address-line1"	3	Normal
   "address-line2"	3	Normal
   "address-line3"	3	Normal
   "locality"	3	Normal
   "region"	3	Normal
   "country"	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
   "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, 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, abort these steps.

7. 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, abort these steps.

8. Let scope tokens be an empty list.

9. Let hint tokens be an empty set.

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

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

12. Decrement index by one.

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

    • "home"
    • "work"
    • "mobile"
    • "fax"
    • "pager"

    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.

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

    • "shipping"
    • "billing"

    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.

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

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

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

18. Insert section at the start of scope tokens.

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

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

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

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

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

24. Abort these steps.

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

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

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

When an element's autofill field name is "off", the user agent should not remember the control's value, 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.

<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 value, and may offer previously stored values to the user.

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 the document's DOM, 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 the user agent prefills 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.

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.

The autocompletion mechanism must be implemented by the user agent acting as if the user had modified the element's value, 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's value must not cause that control to suffer from a type mismatch, suffer from a pattern mismatch, suffer from being too long, suffer from an underflow, suffer from an overflow, or suffer from a step mismatch. 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.

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

<input name=b type=month autocomplete="bday">

<select name=c autocomplete="bday">
 <option>Jan
 <option>Feb
 ...
 <option>Jul
 <option>Aug
 ...
</select>

<input name=a type=number min=1 max=12 autocomplete="bday-month">

<input name=a type=number min=0 max=11 autocomplete="bday-month">

<input name=a type=number min=1 max=11 autocomplete="bday-month">

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. However, user agents should not allow users to trivially override the autofill field name from "off" to "on" or other values, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences.

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.

For input elements, calling these methods while they don't apply, and getting or setting these attributes while they don't apply, must throw an InvalidStateError exception. Otherwise, they must act as described below.

For input elements, these methods and attributes must operate on the element's value. For textarea elements, these methods and attributes must operate on the element's raw value.

Where possible, user interface features for changing the text selection in input and textarea elements must be implemented in terms of the DOM API described in this section, so that, e.g., all the same events fire.

The selections of input and textarea elements have a 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.

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 backwards 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 must cause the contents of the text field to be fully selected, with the selection direction being none, if the platform support selections with the direction none, or otherwise forward. The user agent must then queue a task to fire a simple event that bubbles named select at the element, using the user interaction task source as the task source.

The selectionStart attribute must, on getting, return the offset (in logical order) to the character that immediately follows the start of the selection. If there is no selection, then it must return the offset (in logical order) to the character that immediately follows the text entry cursor.

On setting, it must act as if the setSelectionRange() method had been called, with the new value as the first argument; the current value of the selectionEnd attribute as the second argument, unless the current value of the selectionEnd is less than the new value, in which case the second argument must also be the new value; and the current value of the selectionDirection as the third argument.

The selectionEnd attribute must, on getting, return the offset (in logical order) to the character that immediately follows the end of the selection. If there is no selection, then it must return the offset (in logical order) to the character that immediately follows the text entry cursor.

On setting, it must act as if the setSelectionRange() method had been called, with the current value of the selectionStart attribute as the first argument, the new value as the second argument, and the current value of the selectionDirection as the third argument.

The selectionDirection attribute must, on getting, return the string corresponding to the current selection direction: if the direction is forward, "forward"; if the direction is backward, "backward"; and otherwise, "none".

On setting, it must act as if the setSelectionRange() method had been called, with the current value of the selectionStart attribute as the first argument, the current value of the selectionEnd attribute as the second argument, and the new value as the third argument.

The setSelectionRange(start, end, direction) method must set the selection of the text field to the sequence of characters 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 value of the text field must be treated as pointing at the end of the text field. 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. The direction of the selection must be set to backward if direction is a case-sensitive match for the string "backward", forward if direction is a case-sensitive match for the string "forward" or if the platform does not support selections with the direction none, and none otherwise (including if the argument is omitted). The user agent must then queue a task to fire a simple event that bubbles named select at the element, using the user interaction task source as the task source.

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

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

2. If start is greater than end, then throw an IndexSizeError exception and abort these steps.

3. If start is greater than the length of the value of the text field, then set it to the length of the value of the text field.

4. If end is greater than the length of the value of the text field, then set it to the length of the value of the text field.

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

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

7. If start is less than end, delete the sequence of characters starting with the character at the startth position (in logical order) and ending with the character at the (end-1)th position.

8. Insert the value of the first argument into the text of the value of the text field, immediately before the startth character.

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

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

11. 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", or if the argument was omitted

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

12. Set the selection of the text field to the sequence of characters starting with the character at the selection startth position (in logical order) and ending with the character at the (selection end-1)th position. 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. The direction of the selection must be set to forward if the platform does not support selections with the direction none, and none otherwise.

13. Queue a task to fire a simple event that bubbles named select at the element, using the user interaction task source as the task source.

All elements to which this API applies have either a selection or a text entry cursor position at all times (even for elements that are not being rendered). User agents should follow platform conventions to determine their initial state.

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, select required, textarea required), or, in the case of an element in a radio button group, any of the other elements in the group has a required attribute.

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

When a control has a value that is too low for the min attribute.

Suffering from an overflow

When a control has a value that 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.21.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, run the following substeps:

   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 and abort these steps.

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, run the following substeps:

   1. Fire a simple event named invalid that is cancelable at field.

   2. If the event was not canceled, 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 and abort these steps.

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.

The willValidate attribute must return true if an 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), when invoked, must set the custom validity error message to the value of the given message argument.

The validity attribute must return a ValidityState object that represents the validity states of the element. This object is live, and the same object must be returned each time the element's validity attribute is retrieved.

interface ValidityState {
  readonly attribute boolean valueMissing;
  readonly attribute boolean typeMismatch;
  readonly attribute boolean patternMismatch;
  readonly attribute boolean tooLong;
  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.

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.

When the checkValidity() method is invoked, if the element is a candidate for constraint validation and does not satisfy its constraints, the user agent must fire a simple event named invalid that is cancelable (but in this case has no default action) at the element and return false. Otherwise, it must only return true without doing anything else.

The validationMessage attribute must return the empty string if the element is not a candidate for constraint validation or if it is one but it satisfies its constraints; otherwise, it must 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 the attribute must 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.22.1 Introduction

4.10.22.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 field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.

Consequently, if the default button is disabled, the form is not submitted when such an implicit submission mechanism is used. (A button has no activation behavior when disabled.)

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 and Time, Date, Month, Week, Time, Local Date and Time, Number

4.10.22.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. Let form document be the form's Document.

2. If form document has no associated browsing context or its active sandboxing flag set has its sandboxed forms browsing context flag set, then abort these steps without doing anything.

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

4. 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 a simple event named invalid at the form element and then abort these steps.

5. If the submitted from submit() method flag is not set, then fire a simple event that bubbles and is cancelable named submit, at form. If the event's default action is prevented (i.e. if the event is canceled) then abort these steps. Otherwise, continue (effectively the default action is to perform the submission).

6. Let form data set be the result of constructing the form data set for form in the context of submitter.

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

8. If action is the empty string, let action be the document's address of the form document.

9. Resolve the URL action, relative to the submitter element. If this fails, abort these steps.

10. Let action be the resulting absolute URL.

11. Let action components be the resulting parsed URL.

12. Let scheme be the scheme of the resulting parsed URL.

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

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

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

16. If the user indicated a specific browsing context to use when submitting the form, then let target browsing context be that browsing context. Otherwise, apply the rules for choosing a browsing context given a browsing context name using target as the name and form browsing context as the context in which the algorithm is executed, and let target browsing context be the resulting browsing context.

17. If target browsing context was created in the previous step, or, alternatively, if the form document has not yet completely loaded and the submitted from submit() method is set, then let replace be true. Otherwise, let it be false.

18. 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	Get action URL	Post to data:
    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.

    The behaviors are as follows:

    Mutate action URL

    Let query be the result of encoding the form data set using the application/x-www-form-urlencoded encoding algorithm, interpreted as a US-ASCII string.

    Set parsed action's query component to query.

    Let destination be a new URL formed by applying the URL serializer algorithm to parsed action.

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

    Submit as entity body

    Let entity body be the result of encoding the form data set using the appropriate form encoding algorithm.

    Let MIME type be determined as follows:

    If enctype is application/x-www-form-urlencoded

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

    If enctype is multipart/form-data

    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.

    If enctype is text/plain

    Let MIME type be "text/plain".

    Otherwise, navigate target browsing context to action using the HTTP method given by method and with entity body as the entity body, of type MIME type. If replace is true, then target browsing context must be navigated with replacement enabled.

    Get action URL

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

    The form data set is discarded.

    Post to data:

    Let data be the result of encoding the form data set using the appropriate form encoding algorithm.

    If action contains the string "%%%%" (four U+0025 PERCENT SIGN characters), then percent encode all bytes in data that, if interpreted as US-ASCII, are not characters in the URL default encode set, and then, treating the result as a US-ASCII string, UTF-8 percent encode all the U+0025 PERCENT SIGN characters in the resulting string and replace the first occurrence of "%%%%" in action with the resulting doubly-escaped string. [URL]

    Otherwise, if action contains the string "%%" (two U+0025 PERCENT SIGN characters in a row, but not four), then UTF-8 percent encode all characters in data that, if interpreted as US-ASCII, are not characters in the URL default encode set, and then, treating the result as a US-ASCII string, replace the first occurrence of "%%" in action with the resulting escaped string. [URL]

    Navigate target browsing context to the potentially modified action (which will be a data: URL). If replace is true, then target browsing context must be navigated with replacement enabled.

    Mail with headers

    Let headers be the resulting encoding the form data set using the application/x-www-form-urlencoded encoding algorithm, interpreted as a US-ASCII string.

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

    Let destination consist of all the characters from the first character in action to the character immediately before the first U+003F QUESTION MARK character (?), if any, or the end of the string if there are none.

    Append a single U+003F QUESTION MARK character (?) to destination.

    Append headers to destination.

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

    Mail as body

    Let body be the resulting of encoding the form data set using the appropriate form encoding algorithm and then percent encoding all the bytes in the resulting byte string that, when interpreted as US-ASCII, are not characters in the URL default encode set. [URL]

    Let destination have the same value as action.

    If destination does not contain a U+003F QUESTION MARK character (?), append a single U+003F QUESTION MARK character (?) to destination. Otherwise, append a single U+0026 AMPERSAND character (&).

    Append the string "body=" to destination.

    Append body, interpreted as a US-ASCII string, to destination.

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

    Submit dialog

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

    If there isn't one, 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.

    The appropriate form encoding algorithm is determined as follows:

    If enctype is application/x-www-form-urlencoded

    Use the application/x-www-form-urlencoded encoding algorithm.

    If enctype is multipart/form-data

    Use the multipart/form-data encoding algorithm.

    If enctype is text/plain

    Use the text/plain encoding algorithm.

4.10.22.4 Constructing the form data set

The algorithm to construct the form data set for a form form optionally in the context of a submitter submitter 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 the form data set be a list of name-value-type tuples, initially empty.

3. Loop: For each element field in controls, in tree order, run the following substeps:

   1. If any of the following conditions are met, then skip these substeps for this element:

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

      Otherwise, process field as follows:

   2. Let type be the value of the type IDL attribute of field.

   3. If the field element is an input element whose type attribute is in the Image Button state, then run these further nested substeps:

      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 name_x be the string consisting of the concatenation of name and a single U+0078 LATIN SMALL LETTER X character (x).

      3. Let name_y 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 the form data set with the name name_x, the value x, and the type type.

      6. Append an entry to the form data set with the name name_y and the value y, and the type type.

      7. Skip the remaining substeps for this element: if there are any more elements in controls, return to the top of the loop step, otherwise, jump to the end step below.

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

   5. 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 the form data set with the name as the name, the value of the option element as the value, and type as the type.

   6. Otherwise, if the field element is an input element whose type attribute is in the Checkbox state or the Radio Button state, then run these further nested substeps:

      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 the form data set with name as the name, value as the value, and type as the type.

   7. Otherwise, if the field element is an input element whose type attribute is in the File Upload state, then for each file selected in the input element, append an entry to the form data set with the name as the name, the file (consisting of the name, the type, and the body) as the value, and type as the type. If there are no selected files, then append an entry to the form data set with the name as the name, the empty string as the value, and application/octet-stream as the type.

   8. 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 the form data set with name as the name, the returned form submission value as the value, and the string "object" as the type.

   9. Otherwise, append an entry to the form data set with name as the name, the value of the field element as the value, and type as the type.

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

       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 the form data set with dirname as the name, dir as the value, and the string "direction" as the type.

       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. End: For the name of each entry in the form data set, and for the value of each entry in the form data set whose type is not "file" or "textarea", replace every occurrence of a U+000D CARRIAGE RETURN (CR) character not followed by a U+000A LINE FEED (LF) character, and every occurrence of a U+000A LINE FEED (LF) character not preceded by a U+000D CARRIAGE RETURN (CR) character, by a two-character string consisting of a U+000D CARRIAGE RETURN U+000A LINE FEED (CRLF) character pair.

   In the case of the value of textarea elements, this newline 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). In the case of input elements type attributes in the File Upload state, the value is not normalized.

5. Return the form data set.

4.10.22.5 Selecting a form submission encoding

If the user agent is to pick an encoding for a form, optionally with an allow non-ASCII-compatible encodings flag set, it must run the following 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 spaces.

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 the allow non-ASCII-compatible encodings flag is not set, remove any encodings that are not ASCII-compatible character encodings from candidate encodings.

6. If candidate encodings is empty, return UTF-8 and abort these steps.

7. Each character encoding in candidate encodings can represent a finite number of characters. (For example, UTF-8 can represent all 1.1 million or so Unicode code points, while Windows-1252 can only represent 256.)

   For each encoding in candidate encodings, determine how many of the characters in the names and values of the entries in the form data set the encoding can represent (without ignoring duplicates). Let max be the highest such count. (For UTF-8, max would equal the number of characters in the names and values of the entries in the form data set.)

   Return the first encoding in candidate encodings that can encode max characters in the names and values of the entries in the form data set.

The application/x-www-form-urlencoded encoding algorithm is as follows:

1. Let result be the empty string.

2. If the form element has an accept-charset attribute, let the selected character encoding be the result of picking an encoding for the form.

   Otherwise, if the form element has no accept-charset attribute, but the document's character encoding is an ASCII-compatible character encoding, then that is the selected character encoding.

   Otherwise, let the selected character encoding be UTF-8.

3. Let charset be the name of the selected character encoding.

4. For each entry in the form data set, perform these substeps:

   1. If the entry's name is "_charset_" and its type is "hidden", replace its value with charset.

   2. If the entry's type is "file", replace its value with the file's name only.

   3. 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 Unicode code point of the character in base ten, and finally a U+003B SEMICOLON character (;).

   4. Encode the entry's name and value using the encoder for the selected character encoding. The entry's name and value are now byte strings.

   5. For each byte in the entry's name and value, apply the appropriate subsubsteps from the following list:

      If the byte is 0x20 (U+0020 SPACE if interpreted as ASCII)

      Replace the byte with a single 0x2B byte (U+002B PLUS SIGN character (+) if interpreted as ASCII).

      If the byte is in the range 0x2A, 0x2D, 0x2E, 0x30 to 0x39, 0x41 to 0x5A, 0x5F, 0x61 to 0x7A

      Leave the byte as is.

      Otherwise

      1. Let s be a string consisting of a U+0025 PERCENT SIGN character (%) followed by uppercase ASCII hex digits representing the hexadecimal value of the byte in question (zero-padded if necessary).

      2. Encode the string s as US-ASCII, so that it is now a byte string.

      3. Replace the byte in question in the name or value being processed by the bytes in s, preserving their relative order.

   6. Interpret the entry's name and value as Unicode strings encoded in US-ASCII. (All of the bytes in the string will be in the range 0x00 to 0x7F; the high bit will be zero throughout.) The entry's name and value are now Unicode strings again.

   7. If the entry's name is "isindex", its type is "text", and this is the first entry in the form data set, then append the value to result and skip the rest of the substeps for this entry, moving on to the next entry, if any, or the next step in the overall algorithm otherwise.

   8. If this is not the first entry, append a single U+0026 AMPERSAND character (&) to result.

   9. Append the entry's name to result.

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

   11. Append the entry's value to result.

5. Encode result as US-ASCII and return the resulting byte stream.

The multipart/form-data encoding algorithm is as follows:

1. Let result be the empty string.

2. If the algorithm was invoked with an explicit character encoding, let the selected character encoding be that encoding. (This algorithm is used by other specifications, which provide an explicit character encoding to avoid the dependency on the form element described in the next paragraph.)

   Otherwise, if the form element has an accept-charset attribute, let the selected character encoding be the result of picking an encoding for the form.

   Otherwise, if the form element has no accept-charset attribute, but the document's character encoding is an ASCII-compatible character encoding, then that is the selected character encoding.

   Otherwise, let the selected character encoding be UTF-8.

3. Let charset be the name of the selected character encoding.

4. For each entry in the form data set, perform these substeps:

   1. If the entry's name is "_charset_" and its type is "hidden", replace its value with charset.

   2. 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 Unicode code point of the character in base ten, and finally a U+003B SEMICOLON character (;).

5. Encode the (now mutated) form data set using the rules described by RFC 2388, Returning Values from Forms: multipart/form-data, and return the resulting byte stream. [RFC2388]

   Each entry in the form data set 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 the form data set. Multiple entries with the same name must be treated as distinct fields.

   In particular, this means that multiple files submitted as part of a single <input type=file multiple> element will result in each file having its own field; the "sets of files" feature ("multipart/mixed") of RFC 2388 is not used.

   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 (field names in particular do not get converted to a 7-bit safe encoding as suggested in RFC 2388).

   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). User agents must not use the RFC 2231 encoding suggested by RFC 2388.

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

The text/plain encoding algorithm is as follows:

1. Let result be the empty string.

2. If the form element has an accept-charset attribute, let the selected character encoding be the result of picking an encoding for the form, with the allow non-ASCII-compatible encodings flag unset.

   Otherwise, if the form element has no accept-charset attribute, then that is the selected character encoding.

3. Let charset be the name of the selected character encoding.

4. If the entry's name is "_charset_" and its type is "hidden", replace its value with charset.

5. If the entry's type is "file", replace its value with the file's name only.

6. For each entry in the form data set, perform these substeps:

   1. Append the entry's name to result.

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

   3. Append the entry's value to result.

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

7. Encode result using the encoder for the selected character encoding and return the resulting byte stream.

4.10.23 Resetting a form

When a form element form is reset, the user agent must fire a simple event named reset, that bubbles and is cancelable, at form, and then, if that event is not canceled, must 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).