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

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 missing value default for these attributes is the GET state.

The method of an element is one of those states. If the element is a submit button and has a formmethod attribute, then the element's method is that attribute's state; otherwise, it is the form owner's method attribute's state.

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

The missing value default for these attributes is the application/x-www-form-urlencoded state.

The enctype of an element is one of those three states. If the element is a submit button and has a formenctype attribute, then the element's enctype is that attribute's state; otherwise, it is the form owner's enctype attribute's state.

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

The target of an element is the value of the element's formtarget attribute, if the element is a submit button and has such an attribute; or the value of its form owner's target attribute, if it has such an attribute; or, if the Document contains a base element with a target attribute, then the value of the target attribute of the first such base element; or, if there is no such element, the empty string.

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

4.10.19.6 Autofocusing a form control: the autofocus attribute

The autofocus content attribute allows the author to indicate that a control is to be focused as soon as the page is loaded, allowing the user to just start typing without having to manually focus the main control.

The autofocus attribute is a boolean attribute.

There must not be more than one element in the document with the autofocus attribute specified.

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.

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.

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.19.7 Input modalities: the inputmode attribute

The inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the form control.

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.

The possible keywords and states for the attributes are listed in the following table. The keywords are listed in the first column. Each maps to the state given in the cell in the second column of that keyword's row, and that state has the fallback state given in the cell in the third column of that row.

Keyword State Fallback state Description
verbatim Latin Verbatim Default Alphanumeric Latin-script input of non-prose content, e.g. usernames, passwords, product codes.
latin Latin Text Latin Verbatim Latin-script input in the user's preferred language(s), with some typing aids enabled (e.g. text prediction). Intended for human-to-computer communications, e.g. free-form text search fields.
latin-name Latin Name Latin Text Latin-script input in the user's preferred language(s), with typing aids intended for entering human names enabled (e.g. text prediction from the user's contact list and automatic capitalisation at every word). Intended for situations such as customer name fields.
latin-prose Latin Prose Latin Text Latin-script input in the user's preferred language(s), with aggressive typing aids intended for human-to-human communications enabled (e.g. text prediction and automatic capitalisation at the start of sentences). Intended for situations such as e-mails and instant messaging.
full-width-latin Full-width Latin Latin Prose Latin-script input in the user's secondary language(s), using full-width characters, with aggressive typing aids intended for human-to-human communications enabled (e.g. text prediction and automatic capitalisation at the start of sentences). Intended for latin text embedded inside CJK text.
kana Kana Default Kana or romaji input, typically hiragana input, using full-width characters, with support for converting to kanji. Intended for Japanese text input.
katakana Katakana Kana Katakana input, using full-width characters, with support for converting to kanji. Intended for Japanese text input.
numeric Numeric Default Numeric input, including keys for the digits 0 to 9, the user's preferred thousands separator character, and the character for indicating negative numbers. Intended for numeric codes, e.g. credit card numbers. (For numbers, prefer "<input type=number>".)
tel Telephone Numeric Telephone number input, including keys for the digits 0 to 9, the "#" character, and the "*" character. In some locales, this can also include alphabetic mnemonic labels (e.g. in the US, the key labeled "1" is historically also labeled with the letters A, B, and C). Rarely necessary; use "<input type=tel>" instead.
email E-mail Default Text input in the user's locale, with keys for aiding in the input of e-mail addresses, such as that for the "@" character and the "." character. Rarely necessary; use "<input type=email>" instead.
url URL Default Text input in the user's locale, with keys for aiding in the input of Web addresses, such as that for the "/" and "." characters and for quick input of strings commonly found in domain names such as "www." or ".co.uk". Rarely necessary; use "<input type=url>" instead.

The last three keywords listed above are only provided for completeness, and are rarely necessary, as dedicated input controls exist for their usual use cases (as described in the table above).

User agents must all support the Default input mode state, which corresponds to the user agent's default input modality. This specification does not define how the user agent's default modality is to operate. The missing value default is the default input mode state.

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.

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

The attribute, if present, must have a value that is a 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 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:     <input name=ba autocomplete="section-blue shipping street-address"> </label>
 <p> <label> City:        <input name=bc autocomplete="section-blue shipping region"> </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:     <input name=ra autocomplete="section-red shipping street-address"> </label>
 <p> <label> City:        <input name=rc autocomplete="section-red shipping region"> </label>
 <p> <label> Postal Code: <input name=rp autocomplete="section-red shipping country"> </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:

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 him; 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 fields names 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 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.

Field name Meaning Example
"name" Full name Sir Timothy John Berners-Lee, OM, KBE, FRS, FREng, FRSA
"honorific-prefix" Prefix or title (e.g. "Mr.", "Ms.", "Dr.", "Mlle") Sir
"given-name" Given name (in some Western cultures, also known as the first name) Timothy
"additional-name" Additional names (in some Western cultures, also known as middle names, forenames other than the first name) John
"family-name" Family name (in some Western cultures, also known as the last name or surname) Berners-Lee
"honorific-suffix" Suffix (e.g. "Jr.", "B.Sc.", "MBASW", "II") OM, KBE, FRS, FREng, FRSA
"nickname" Nickname, screen name, handle: a typically short name used instead of the full name Tim
"organization-title" Job title (e.g. "Software Engineer", "Senior Vice President", "Deputy Managing Director") Professor
"organization" Company name corresponding to the person, address, or contact information in the other fields associated with this field World Wide Web Consortium
"street-address" Street address (as one line) 32 Vassar Street; MIT Room 32-G524
"address-line1" Street address (as multiple lines) 32 Vassar Street
"address-line2" MIT Room 32-G524
"address-line3"
"locality" City, town, village, or other locality within which the relevant street address is found Cambridge
"region" Provice such as a state, county, or canton within which the locality is found MA
"country" Country USA
"postal-code" Postal code, post code, ZIP code 02139
"cc-name" Full name as given on the payment instrument Tim Berners-Lee
"cc-given-name" Given name as given on the payment instrument (in some Western cultures, also known as the first name) Tim
"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)
"cc-family-name" Family name given on the payment instrument (in some Western cultures, also known as the last name or surname) Berners-Lee
"cc-number" Code identifying the payment instrument (e.g. the credit card number) 4114360123456785
"cc-exp" Expiration date of the payment instrument 2014-12
"cc-exp-month" Month component of the expiration date of the payment instrument 12
"cc-exp-year" Year component of the expiration date of the payment instrument 2014
"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) 419
"language" Preferred language English
"bday" Birthday 1955-06-08
"bday-day" Day component of birthday 8
"bday-month" Month component of birthday June
"bday-year" Year component of birthday 1955
"sex" Gender identity (e.g. Female, Fa'afafine) Male
"url" Home page or other Web page corresponding to the company, person, address, or contact information in the other fields associated with this field http://www.w3.org/People/Berners-Lee/
"photo" Photograph, icon, or other image corresponding to the company, person, address, or contact information in the other fields associated with this field http://www.w3.org/Press/Stock/Berners-Lee/2001-europaeum-eighth.jpg
"tel" Full telephone number, including country code +1 617 253 5702
"tel-country-code" Country code component of the telephone number +1
"tel-national" Telephone number without the county code component 617 253 5702
"tel-area-code" Area code component of the telephone number 617
"tel-local" Telephone number without the country code and area code components 2535702
"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 253
"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 5702
"tel-extension" Telephone number internal extension code 1000
"email" E-mail address timbl@w3.org
"impp" URL representing an instant messaging protocol endpoint (for example, "aim:goim?screenname=example" or xmpp:fred@example.net") irc://example.org/timbl,isuser

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.

Each input, select, and textarea element has an autofill hint set, 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
    "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:

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

    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. Decrement index by one.

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

  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:

    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 contact to hint set.

    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 either be field or the concatenation of contact, a space, and field).

    5. Decrement index by one.

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

  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 field name be field.

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

  23. Abort these steps.

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

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

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

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 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 hint set must use data relating to the same person, address, payment instrument, and/or 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 pefilled 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, 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. 
<select name=c>
 <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 recognising 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. 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.