HTML Living Standard — Last Updated

4.10.5 The input element

✔ MDN Element/input Support in all current engines. Firefox 1+ Safari 1+ Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS 1+ Chrome Android Yes WebView Android 1+ Samsung Internet Yes Opera Android Yes Element/input

✔ MDN HTMLInputElement Support in all current engines. Firefox 1+ Safari 3+ Chrome 1+ Opera 8+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 8+ Firefox Android 4+ Safari iOS 1+ Chrome Android 18+ WebView Android 1+ Samsung Internet 1.0+ Opera Android 10.1+

The input element represents a typed data field, usually with a form control to allow the user to edit the data.

The type attribute controls the data type (and associated control) of the element. It is an enumerated attribute. The following table lists the keywords and states for the attribute — the keywords in the left column map to the states in the cell in the second column on the same row as the keyword.

Keyword State Data type Control type hidden Hidden An arbitrary string n/a text Text Text with no line breaks A text control search Search Text with no line breaks Search control tel Telephone Text with no line breaks A text control url URL An absolute URL A text control email Email An email address or list of email addresses A text control password Password Text with no line breaks (sensitive information) A text control that obscures data entry A date (year, month, day) with no time zone A date control month Month A date consisting of a year and a month with no time zone A month control week Week A date consisting of a week-year number and a week number with no time zone A week control time Time A time (hour, minute, seconds, fractional seconds) with no time zone A time control A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone A date and time control number Number A numerical value A text control or spinner control range Range A numerical value, with the extra semantic that the exact value is not important A slider control or similar color Color An sRGB color with 8-bit red, green, and blue components A color picker checkbox Checkbox A set of zero or more values from a predefined list A checkbox radio Radio Button An enumerated value A radio button file File Upload Zero or more files each with a MIME type and optionally a file name A label and a button submit Submit Button An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission A button image Image Button A coordinate, relative to a particular image's size, with the extra semantic that it must be the last value selected and initiates form submission Either a clickable image, or a button reset Reset Button n/a A button button Button n/a A button

The missing value default and the invalid value default are the Text state.

Which of the accept , alt , autocomplete , checked , dirname , formaction , formenctype , formmethod , , formtarget , height , list , max , maxlength , min , minlength , multiple , pattern , placeholder , readonly , required , size , src , step , and width content attributes, the checked , files , , valueAsNumber , and list IDL attributes, the select() method, the selectionStart , selectionEnd , and selectionDirection , IDL attributes, the setRangeText() and setSelectionRange() methods, the stepUp() and stepDown() methods, and the input and change events apply to an input element depends on the state of its type attribute. The subsections that define each type also clearly define in normative "bookkeeping" sections which of these feature apply, and which do not apply , to each type. The behavior of these features depends on whether they apply or not, as defined in their various sections (q.v. for content attributes, for APIs, for events).

The following table is non-normative and summarizes which of those content attributes, IDL attributes, methods, and events apply to each state:

† If the control has no selectable text, the select() method results in a no-op, with no " InvalidStateError " DOMException .

Some states of the type attribute define a value sanitization algorithm .

Each input element has a value, which is exposed by the value IDL attribute. Some states define an algorithm to convert a string to a number , an algorithm to convert a number to a string , an , and an , which are used by max , min , step , , valueAsNumber , and stepUp() .

An input element's dirty value flag must be set to true whenever the user interacts with the control in a way that changes the value. (It is also set to true when the value is programmatically changed, as described in the definition of the value IDL attribute.)

The value content attribute gives the default value of the input element. When the value content attribute is added, set, or removed, if the control's dirty value flag is false, the user agent must set the value of the element to the value of the value content attribute, if there is one, or the empty string otherwise, and then run the current value sanitization algorithm, if one is defined.

Each input element has a checkedness, which is exposed by the checked IDL attribute.

Each input element has a boolean dirty checkedness flag . When it is true, the element is said to have a dirty checkedness . The dirty checkedness flag must be initially set to false when the element is created, and must be set to true whenever the user interacts with the control in a way that changes the checkedness.

The checked content attribute is a boolean attribute that gives the default checkedness of the input element. When the checked content attribute is added, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to true; when the checked content attribute is removed, if the control does not have dirty checkedness, the user agent must set the checkedness of the element to false.

The reset algorithm for input elements is to set the dirty value flag and dirty checkedness flag back to false, set the value of the element to the value of the value content attribute, if there is one, or the empty string otherwise, set the checkedness of the element to true if the element has a checked content attribute and false if it does not, empty the list of selected files, and then invoke the value sanitization algorithm, if the type attribute's current state defines one.

Each input element can be mutable. Except where otherwise specified, an input element is always mutable. Similarly, except where otherwise specified, the user agent should not allow the user to modify the element's value or checkedness.

When an input element is disabled, it is not mutable.

The readonly attribute can also in some cases (e.g. for the state, but not the Checkbox state) stop an input element from being mutable.

The cloning steps for input elements must propagate the value, dirty value flag, checkedness, and dirty checkedness flag from the node being cloned to the copy.

The activation behavior for input elements are these steps:

If this element is not mutable and is not in the Checkbox state and is not in the Radio state, then return. Run this element's input activation behavior , if any, and do nothing otherwise.

The legacy-pre-activation behavior for input elements are these steps:

If this element's type attribute is in the Checkbox state, then set this element's checkedness to its opposite value (i.e. true if it is false, false if it is true) and set this element's indeterminate IDL attribute to false. If this element's type attribute is in the Radio Button state, then get a reference to the element in this element's radio button group that has its checkedness set to true, if any, and then set this element's checkedness to true.

The legacy-canceled-activation behavior for input elements are these steps:

When an input element is first created, the element's rendering and behavior must be set to the rendering and behavior defined for the type attribute's state, and the value sanitization algorithm, if one is defined for the type attribute's state, must be invoked.

The name attribute represents the element's name. The dirname attribute controls how the element's directionality is submitted. The disabled attribute is used to make the control non-interactive and to prevent its value from being submitted. The form attribute is used to explicitly associate the input element with its form owner. The autocomplete attribute controls how the user agent provides autofill behavior.

✔ MDN HTMLInputElement#indeterminate Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer ? Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

The indeterminate IDL attribute must initially be set to false. On getting, it must return the last value it was set to. On setting, it must be set to the new value. It has no effect except for changing the appearance of checkbox controls.

The accept , alt , max , min , multiple , pattern , placeholder , required , size , src , and step IDL attributes must reflect the respective content attributes of the same name. The dirName IDL attribute must reflect the dirname content attribute. The readOnly IDL attribute must reflect the readonly content attribute. The defaultChecked IDL attribute must reflect the checked content attribute. The defaultValue IDL attribute must reflect the value content attribute.

The type IDL attribute must reflect the respective content attribute of the same name, limited to only known values. The maxLength IDL attribute must reflect the maxlength content attribute, limited to only non-negative numbers. The minLength IDL attribute must reflect the minlength content attribute, limited to only non-negative numbers.

The IDL attributes width and height must return the rendered width and height of the image, in CSS pixels, if an image is being rendered, and is being rendered to a visual medium; or else the intrinsic width and height of the image, in CSS pixels, if an image is available but not being rendered to a visual medium; or else 0, if no image is available. When the input element's type attribute is not in the Image Button state, then no image is available. [CSS]

On setting, they must act as if they reflected the respective content attributes of the same name.

The , validity , and validationMessage IDL attributes, and the checkValidity() , reportValidity() , and setCustomValidity() methods, are part of the constraint validation API. The labels IDL attribute provides a list of the element's label s. The select() , selectionStart , selectionEnd , selectionDirection , setRangeText() , and setSelectionRange() methods and IDL attributes expose the element's text selection. The disabled , form , and name IDL attributes are part of the element's forms API.

4.10.5.1 States of the type attribute

4.10.5.1.1 Hidden state ( type=hidden )

✔ MDN Element/input/hidden Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera 2+ Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Hidden state, the rules in this section apply.

The input element represents a value that is not intended to be examined or manipulated by the user.

Constraint validation: If an input element's type attribute is in the Hidden state, it is barred from constraint validation.

If the name attribute is present and has a value that is identical to " _charset_ ", then the element's value attribute must be omitted.

4.10.5.1.2 Text ( type=text ) state and Search state ( type=search )

✔ MDN Element/input/search Support in all current engines. Firefox 4+ Safari 5+ Chrome 5+ Opera 10.6+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table Element/input/text Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

When an input element's type attribute is in the Text state or the Search state, the rules in this section apply.

The input element represents a one line plain text edit control for the element's value.

The difference between the Text state and the Search state is primarily stylistic: on platforms where search controls are distinguished from regular text controls, the Search state might result in an appearance consistent with the platform's search controls rather than appearing like a regular text control.

If the element is mutable, its value should be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value.

If the element is mutable, the user agent should allow the user to change the writing direction of the element, setting it either to a left-to-right writing direction or a right-to-left writing direction. If the user does so, the user agent must then run the following steps:

The value attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.

The value sanitization algorithm is as follows: Strip newlines from the value.

4.10.5.1.3 Telephone state ( type=tel )

✔ MDN Element/input/tel Support in all current engines. Firefox Yes Safari 4+ Chrome 3+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android Yes Safari iOS 3+ Chrome Android 18+ WebView Android 37+ Samsung Internet 1.0+ Opera Android 11+ caniuse.com table

When an input element's type attribute is in the Telephone state, the rules in this section apply.

The input element represents a control for editing a telephone number given in the element's value.

If the element is mutable, its value should be editable by the user. User agents may change the spacing and, with care, the punctuation of values that the user enters. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the element's value.

The value attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.

The value sanitization algorithm is as follows: Strip newlines from the value.

Unlike the URL and Email types, the Telephone type does not enforce a particular syntax. This is intentional; in practice, telephone number fields tend to be free-form fields, because there are a wide variety of valid phone numbers. Systems that need to enforce a particular format are encouraged to use the pattern attribute or the setCustomValidity() method to hook into the client-side validation mechanism.

4.10.5.1.4 URL state ( type=url )

✔ MDN Element/input/url Support in all current engines. Firefox Yes Safari Yes Chrome 1+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the URL state, the rules in this section apply.

The input element represents a control for editing a single absolute URL given in the element's value.

If the element is mutable, the user agent should allow the user to change the URL represented by its value. User agents may allow the user to set the value to a string that is not a valid absolute URL, but may also or instead automatically escape characters entered by the user so that the value is always a valid absolute URL (even if that isn't the actual value seen and edited by the user in the interface). User agents should allow the user to set the value to the empty string. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the value.

The value attribute, if specified and not empty, must have a value that is a valid URL potentially surrounded by spaces that is also an absolute URL.

The value sanitization algorithm is as follows: Strip newlines from the value, then strip leading and trailing ASCII whitespace from the value.

Constraint validation: While the value of the element is neither the empty string nor a valid absolute URL, the element is suffering from a type mismatch.

If a document contained the following markup: < input type = "url" name = "location" list = "urls" > < datalist id = "urls" > < option label = "MIME: Format of Internet Message Bodies" value = "https://tools.ietf.org/html/rfc2045" > < option label = "HTML" value = "https://html.spec.whatwg.org/" > < option label = "DOM" value = "https://dom.spec.whatwg.org/" > < option label = "Fullscreen" value = "https://fullscreen.spec.whatwg.org/" > < option label = "Media Session" value = "https://mediasession.spec.whatwg.org/" > < option label = "The Single UNIX Specification, Version 3" value = "http://www.unix.org/version3/" > </ datalist > ...and the user had typed " spec.w ", and the user agent had also found that the user had visited https://url.spec.whatwg.org/#url-parsing and https://streams.spec.whatwg.org/ in the recent past, then the rendering might look like this: The first four URLs in this sample consist of the four URLs in the author-specified list that match the text the user has entered, sorted in some implementation-defined manner (maybe by how frequently the user refers to those URLs). Note how the UA is using the knowledge that the values are URLs to allow the user to omit the scheme part and perform intelligent matching on the domain name. The last two URLs (and probably many more, given the scrollbar's indications of more values being available) are the matches from the user agent's session history data. This data is not made available to the page DOM. In this particular case, the UA has no titles to provide for those values.

4.10.5.1.5 Email state ( type=email )

✔ MDN Element/input/email Support in all current engines. Firefox Yes Safari Yes Chrome 5+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android 4+ Safari iOS 3.1+ Chrome Android ? WebView Android ? Samsung Internet ? Opera Android Yes

When an input element's type attribute is in the Email state, the rules in this section apply.

How the Email state operates depends on whether the multiple attribute is specified or not.

When the multiple attribute is set or removed, the user agent must run the value sanitization algorithm.

A valid email address is a string that matches the email production of the following ABNF, the character set for which is Unicode. This ABNF implements the extensions described in RFC 1123. [ABNF] [RFC5322] [RFC1034] [RFC1123]

This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

The following JavaScript- and Perl-compatible regular expression is an implementation of the above definition. /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

A valid email address list is a set of comma-separated tokens, where each token is itself a valid email address. To obtain the list of tokens from a valid email address list, an implementation must split the string on commas.

4.10.5.1.6 Password state ( type=password )

✔ MDN Element/input/password Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera 2+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 2+ Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android ? Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Password state, the rules in this section apply.

The input element represents a one line plain text edit control for the element's value. The user agent should obscure the value so that people other than the user cannot see it.

If the element is mutable, its value should be editable by the user. User agents must not allow users to insert U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters into the value.

The value attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.

The value sanitization algorithm is as follows: Strip newlines from the value.

✔ MDN Element/input/date Support in all current engines. Firefox 57+ Safari No Chrome 20+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer No Firefox Android 57+ Safari iOS 5+ Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android 11+ caniuse.com table

When an element's attribute is in the state, the rules in this section apply.

The element a control for setting the element's to a string representing a specific .

If the element is , the user agent should allow the user to change the represented by its , as obtained by from it. User agents must not allow the user to set the to a non-empty string that is not a . If the user agent provides a user interface for selecting a , then the must be set to a representing the user's selection. User agents should allow the user to set the to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a , the control is .

See the introduction section for a discussion of the difference between the input format and submission format for date, time, and number form controls, and the implementation notes regarding localization of form controls.

The attribute, if specified and not empty, must have a value that is a .

The is as follows: If the of the element is not a , then set it to the empty string instead.

The attribute, if specified, must have a value that is a . The attribute, if specified, must have a value that is a .

The attribute is expressed in days. The is 86,400,000 (which converts the days to milliseconds, as used in the other algorithms). The is 1 day.

When the element is , the user agent may round the element's to the nearest for which the element would not .

The , given a string input , is as follows: If from input results in an error, then return an error; otherwise, return the number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0Z ") to midnight UTC on the morning of the parsed , ignoring leap seconds.

The , given a number input , is as follows: Return a that represents the that, in UTC, is current input milliseconds after midnight UTC on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0Z ").

The , given a string input , is as follows: If from input results in an error, then return an error; otherwise, return representing midnight UTC on the morning of the parsed .

The , given a object input , is as follows: Return a that represents the current at the time represented by input in the UTC time zone.

The state (and other date- and time-related states described in subsequent sections) is not intended for the entry of values for which a precise date and time relative to the contemporary calendar cannot be established. For example, it would be inappropriate for the entry of times like "one millisecond after the big bang", "the early part of the Jurassic period", or "a winter around 250 BCE". For the input of dates before the introduction of the Gregorian calendar, authors are encouraged to not use the state (and the other date- and time-related states described in subsequent sections), as user agents are not required to support converting dates and times from earlier periods to the Gregorian calendar, and asking users to do so manually puts an undue burden on users. (This is complicated by the manner in which the Gregorian calendar was phased in, which occurred at different times in different countries, ranging from partway through the 16th century all the way to early in the 20th.) Instead, authors are encouraged to provide fine-grained input controls using the element and elements with the state.

The following common element content attributes, IDL attributes, and methods to the element: , , , , , , and content attributes; , , , and IDL attributes; , , and methods. The IDL attribute is in mode . The and events . The following content attributes must not be specified and to the element: , , , , , , , , , , , , , , , , , and . The following IDL attributes and methods to the element: , , , and IDL attributes; , and methods.

4.10.5.1.8 Month state ( type=month )

MDN Element/input/month Firefox No Safari No Chrome 20+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer No Firefox Android No Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Month state, the rules in this section apply.

The input element represents a control for setting the element's value to a string representing a specific month.

If the element is mutable, the user agent should allow the user to change the month represented by its value, as obtained by parsing a month from it. User agents must not allow the user to set the value to a non-empty string that is not a valid month string. If the user agent provides a user interface for selecting a month, then the value must be set to a valid month string representing the user's selection. User agents should allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid month string, the control is suffering from bad input.

See the introduction section for a discussion of the difference between the input format and submission format for date, time, and number form controls, and the implementation notes regarding localization of form controls.

The value attribute, if specified and not empty, must have a value that is a valid month string.

The value sanitization algorithm is as follows: If the value of the element is not a valid month string, then set it to the empty string instead.

The min attribute, if specified, must have a value that is a valid month string. The max attribute, if specified, must have a value that is a valid month string.

The step attribute is expressed in months. The step scale factor is 1 (there is no conversion needed as the algorithms use months). The default step is 1 month.

When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest month for which the element would not suffer from a step mismatch.

The algorithm to convert a string to a number, given a string input , is as follows: If parsing a month from input results in an error, then return an error; otherwise, return the number of months between January 1970 and the parsed month.

The algorithm to convert a number to a string, given a number input , is as follows: Return a valid month string that represents the month that has input months between it and January 1970.

The , given a string input , is as follows: If parsing a month from input results in an error, then return an error; otherwise, return representing midnight UTC on the morning of the first day of the parsed month.

The , given a object input , is as follows: Return a valid month string that represents the month current at the time represented by input in the UTC time zone.

4.10.5.1.9 Week state ( type=week )

✔ MDN Element/input/week Support in all current engines. Firefox No Safari No Chrome 20+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer No Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Week state, the rules in this section apply.

The input element represents a control for setting the element's value to a string representing a specific week.

If the element is mutable, the user agent should allow the user to change the week represented by its value, as obtained by parsing a week from it. User agents must not allow the user to set the value to a non-empty string that is not a valid week string. If the user agent provides a user interface for selecting a week, then the value must be set to a valid week string representing the user's selection. User agents should allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid week string, the control is suffering from bad input.

See the introduction section for a discussion of the difference between the input format and submission format for date, time, and number form controls, and the implementation notes regarding localization of form controls.

The value attribute, if specified and not empty, must have a value that is a valid week string.

The value sanitization algorithm is as follows: If the value of the element is not a valid week string, then set it to the empty string instead.

The min attribute, if specified, must have a value that is a valid week string. The max attribute, if specified, must have a value that is a valid week string.

The step attribute is expressed in weeks. The step scale factor is 604,800,000 (which converts the weeks to milliseconds, as used in the other algorithms). The default step is 1 week. The default step base is −259,200,000 (the start of week 1970-W01).

When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest week for which the element would not suffer from a step mismatch.

The algorithm to convert a string to a number, given a string input , is as follows: If parsing a week string from input results in an error, then return an error; otherwise, return the number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0Z ") to midnight UTC on the morning of the Monday of the parsed week, ignoring leap seconds.

The algorithm to convert a number to a string, given a number input , is as follows: Return a valid week string that represents the week that, in UTC, is current input milliseconds after midnight UTC on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0Z ").

The , given a string input , is as follows: If parsing a week from input results in an error, then return an error; otherwise, return representing midnight UTC on the morning of the Monday of the parsed week.

The , given a object input , is as follows: Return a valid week string that represents the week current at the time represented by input in the UTC time zone.

4.10.5.1.10 Time state ( type=time )

✔ MDN Element/input/time Support in all current engines. Firefox 57+ Safari No Chrome 20+ Opera 10+ Edge 79+ Edge (Legacy) 12+ Internet Explorer No Firefox Android 57+ Safari iOS Yes Chrome Android 25+ WebView Android Yes Samsung Internet 1.5+ Opera Android Yes

When an input element's type attribute is in the Time state, the rules in this section apply.

The input element represents a control for setting the element's value to a string representing a specific time.

If the element is mutable, the user agent should allow the user to change the time represented by its value, as obtained by parsing a time from it. User agents must not allow the user to set the value to a non-empty string that is not a valid time string. If the user agent provides a user interface for selecting a time, then the value must be set to a valid time string representing the user's selection. User agents should allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid time string, the control is suffering from bad input.

See the introduction section for a discussion of the difference between the input format and submission format for date, time, and number form controls, and the implementation notes regarding localization of form controls.

The value attribute, if specified and not empty, must have a value that is a valid time string.

The value sanitization algorithm is as follows: If the value of the element is not a valid time string, then set it to the empty string instead.

The form control has a periodic domain.

The min attribute, if specified, must have a value that is a valid time string. The max attribute, if specified, must have a value that is a valid time string.

The step attribute is expressed in seconds. The step scale factor is 1000 (which converts the seconds to milliseconds, as used in the other algorithms). The default step is 60 seconds.

When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest time for which the element would not suffer from a step mismatch.

The algorithm to convert a string to a number, given a string input , is as follows: If parsing a time from input results in an error, then return an error; otherwise, return the number of milliseconds elapsed from midnight to the parsed time on a day with no time changes.

The algorithm to convert a number to a string, given a number input , is as follows: Return a valid time string that represents the time that is input milliseconds after midnight on a day with no time changes.

The , given a string input , is as follows: If parsing a time from input results in an error, then return an error; otherwise, return representing the parsed time in UTC on 1970-01-01.

The , given a object input , is as follows: Return a valid time string that represents the UTC time component that is represented by input .

✔ MDN Element/input/datetime-local Support in all current engines. Firefox No Safari No Chrome 20+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer No Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android 11+

When an element's attribute is in the state, the rules in this section apply.

The element a control for setting the element's to a string representing a , with no time-zone offset information.

If the element is , the user agent should allow the user to change the represented by its , as obtained by from it. User agents must not allow the user to set the to a non-empty string that is not a . If the user agent provides a user interface for selecting a , then the must be set to a representing the user's selection. User agents should allow the user to set the to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a , the control is .

See the introduction section for a discussion of the difference between the input format and submission format for date, time, and number form controls, and the implementation notes regarding localization of form controls.

The attribute, if specified and not empty, must have a value that is a .

The is as follows: If the of the element is a , then set it to a representing the same date and time; otherwise, set it to the empty string instead.

The attribute, if specified, must have a value that is a . The attribute, if specified, must have a value that is a .

The attribute is expressed in seconds. The is 1000 (which converts the seconds to milliseconds, as used in the other algorithms). The is 60 seconds.

When the element is , the user agent may round the element's to the nearest for which the element would not .

The , given a string input , is as follows: If from input results in an error, then return an error; otherwise, return the number of milliseconds elapsed from midnight on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0 ") to the parsed , ignoring leap seconds.

The , given a number input , is as follows: Return a that represents the date and time that is input milliseconds after midnight on the morning of 1970-01-01 (the time represented by the value " 1970-01-01T00:00:00.0 ").

See the note on historical dates in the state section.

The following common element content attributes, IDL attributes, and methods to the element: , , , , , , and content attributes; , , and IDL attributes; , , and methods. The IDL attribute is in mode . The and events . The following content attributes must not be specified and to the element: , , , , , , , , , , , , , , , , , and . The following IDL attributes and methods to the element: , , , , , and IDL attributes; , and methods.

The following example shows part of a flight booking application. The application uses an element with its attribute set to , and it then interprets the given date and time in the time zone of the selected airport. < fieldset > < legend > Destination </ legend > < p >< label > Airport: < input type = text name = to list = airports ></ label ></ p > < p >< label > Departure time: < input type = datetime-local name = totime step = 3600 ></ label ></ p > </ fieldset > < datalist id = airports > < option value = ATL label = "Atlanta" > < option value = MEM label = "Memphis" > < option value = LHR label = "London Heathrow" > < option value = LAX label = "Los Angeles" > < option value = FRA label = "Frankfurt" > </ datalist >

4.10.5.1.12 Number state ( type=number )

✔ MDN Element/input/number Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

When an input element's type attribute is in the Number state, the rules in this section apply.

The input element represents a control for setting the element's value to a string representing a number.

If the element is mutable, the user agent should allow the user to change the number represented by its value, as obtained from applying the rules for parsing floating-point number values to it. User agents must not allow the user to set the value to a non-empty string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to the best representation of the number representing the user's selection as a floating-point number. User agents should allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid floating-point number, the control is suffering from bad input.

This specification does not define what user interface user agents are to use; user agent vendors are encouraged to consider what would best serve their users' needs. For example, a user agent in Persian or Arabic markets might support Persian and Arabic numeric input (converting it to the format required for submission as described above). Similarly, a user agent designed for Romans might display the value in Roman numerals rather than in decimal; or (more realistically) a user agent designed for the French market might display the value with apostrophes between thousands and commas before the decimals, and allow the user to enter a value in that manner, internally converting it to the submission format described above.

The value attribute, if specified and not empty, must have a value that is a valid floating-point number.

The value sanitization algorithm is as follows: If the value of the element is not a valid floating-point number, then set it to the empty string instead.

The min attribute, if specified, must have a value that is a valid floating-point number. The max attribute, if specified, must have a value that is a valid floating-point number.

The step scale factor is 1. The default step is 1 (allowing only integers to be selected by the user, unless the step base has a non-integer value).

When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest number for which the element would not suffer from a step mismatch. If there are two such numbers, user agents are encouraged to pick the one nearest positive infinity.

The algorithm to convert a string to a number, given a string input , is as follows: If applying the rules for parsing floating-point number values to input results in an error, then return an error; otherwise, return the resulting number.

The algorithm to convert a number to a string, given a number input , is as follows: Return a valid floating-point number that represents input .

Here is an example of using a numeric input control: < label > How much do you want to charge? $ < input type = number min = 0 step = 0.01 name = price ></ label > As described above, a user agent might support numeric input in the user's local format, converting it to the format required for submission as described above. This might include handling grouping separators (as in "872,000,000,000") and various decimal separators (such as "3,99" vs "3.99") or using local digits (such as those in Arabic, Devanagari, Persian, and Thai).

The type=number state is not appropriate for input that happens to only consist of numbers but isn't strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g. with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn't a minor mistake, it's as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with an inputmode or pattern attribute).

4.10.5.1.13 Range state ( type=range )

✔ MDN Element/input/range Support in all current engines. Firefox 23+ Safari 3.1+ Chrome 4+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android 52+ Safari iOS 5.1+ Chrome Android 57+ WebView Android 4.4+ Samsung Internet 7.0+ Opera Android Yes caniuse.com table

When an input element's type attribute is in the Range state, the rules in this section apply.

The input element represents a control for setting the element's value to a string representing a number, but with the caveat that the exact value is not important, letting UAs provide a simpler interface than they do for the Number state.

If the element is mutable, the user agent should allow the user to change the number represented by its value, as obtained from applying the rules for parsing floating-point number values to it. User agents must not allow the user to set the value to a string that is not a valid floating-point number. If the user agent provides a user interface for selecting a number, then the value must be set to a best representation of the number representing the user's selection as a floating-point number. User agents must not allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid floating-point number, the control is suffering from bad input.

The value attribute, if specified, must have a value that is a valid floating-point number.

The value sanitization algorithm is as follows: If the value of the element is not a valid floating-point number, then set it to the best representation, as a floating-point number, of the default value.

The default value is the minimum plus half the difference between the minimum and the maximum, unless the maximum is less than the minimum, in which case the default value is the minimum.

When the element is suffering from an underflow, the user agent must set the element's value to the best representation, as a floating-point number, of the minimum.

When the element is suffering from an overflow, if the maximum is not less than the minimum, the user agent must set the element's value to a valid floating-point number that represents the maximum.

When the element is suffering from a step mismatch, the user agent must round the element's value to the nearest number for which the element would not suffer from a step mismatch, and which is greater than or equal to the minimum, and, if the maximum is not less than the minimum, which is less than or equal to the maximum, if there is a number that matches these constraints. If two numbers match these constraints, then user agents must use the one nearest to positive infinity.

For example, the markup <input type="range" min=0 max=100 step=20 value=50> results in a range control whose initial value is 60.

Here is an example of a range control using an autocomplete list with the list attribute. This could be useful if there are values along the full range of the control that are especially important, such as preconfigured light levels or typical speed limits in a range control used as a speed control. The following markup fragment: < input type = "range" min = "-100" max = "100" value = "0" step = "10" name = "power" list = "powers" > < datalist id = "powers" > < option value = "0" > < option value = "-30" > < option value = "30" > < option value = "++50" > </ datalist > ...with the following style sheet applied: input { height : 75 px ; width : 49 px ; background : #D5CCBB ; color : black ; } ...might render as: Note how the UA determined the orientation of the control from the ratio of the style-sheet-specified height and width properties. The colors were similarly derived from the style sheet. The tick marks, however, were derived from the markup. In particular, the step attribute has not affected the placement of tick marks, the UA deciding to only use the author-specified completion values and then adding longer tick marks at the extremes. Note also how the invalid value ++50 was completely ignored.

For another example, consider the following markup fragment: < input name = x type = range min = 100 max = 700 step = 9.09090909 value = 509.090909 > A user agent could display in a variety of ways, for instance: Or, alternatively, for instance: The user agent could pick which one to display based on the dimensions given in the style sheet. This would allow it to maintain the same resolution for the tick marks, despite the differences in width.

Finally, here is an example of a range control with two labeled values: < input type = "range" name = "a" list = "a-values" > < datalist id = "a-values" > < option value = "10" label = "Low" > < option value = "90" label = "High" > </ datalist > With styles that make the control draw vertically, it might look as follows:

In this state, the range and step constraints are enforced even during user input, and there is no way to set the value to the empty string.

The min attribute, if specified, must have a value that is a valid floating-point number. The default minimum is 0. The max attribute, if specified, must have a value that is a valid floating-point number. The default maximum is 100.

The step scale factor is 1. The default step is 1 (allowing only integers, unless the min attribute has a non-integer value).

The algorithm to convert a string to a number, given a string input , is as follows: If applying the rules for parsing floating-point number values to input results in an error, then return an error; otherwise, return the resulting number.

The algorithm to convert a number to a string, given a number input , is as follows: Return the best representation, as a floating-point number, of input .

4.10.5.1.14 Color state ( type=color )

✔ MDN Element/input/color Support in all current engines. Firefox 29+ Safari 12.1+ Chrome 20+ Opera 12+ Edge 79+ Edge (Legacy) 14+ Internet Explorer No Firefox Android 27+ Safari iOS 12.2+ Chrome Android 25+ WebView Android 4.4+ Samsung Internet 1.5+ Opera Android 12+ caniuse.com table

When an input element's type attribute is in the Color state, the rules in this section apply.

The input element represents a color well control, for setting the element's value to a string representing a simple color.

In this state, there is always a color picked, and there is no way to set the value to the empty string.

If the element is mutable, the user agent should allow the user to change the color represented by its value, as obtained from applying the rules for parsing simple color values to it. User agents must not allow the user to set the value to a string that is not a valid lowercase simple color. If the user agent provides a user interface for selecting a color, then the value must be set to the result of using the rules for serializing simple color values to the user's selection. User agents must not allow the user to set the value to the empty string.

Constraint validation: While the user interface describes input that the user agent cannot convert to a valid lowercase simple color, the control is suffering from bad input.

The value attribute, if specified and not empty, must have a value that is a valid simple color.

The value sanitization algorithm is as follows: If the value of the element is a valid simple color, then set it to the value of the element converted to ASCII lowercase; otherwise, set it to the string " #000000 ".

4.10.5.1.15 Checkbox state ( type=checkbox )

✔ MDN Element/input/checkbox Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Checkbox state, the rules in this section apply.

The input element represents a two-state control that represents the element's checkedness state. If the element's checkedness state is true, the control represents a positive selection, and if it is false, a negative selection. If the element's indeterminate IDL attribute is set to true, then the control's selection should be obscured as if the control was in a third, indeterminate, state.

The control is never a true tri-state control, even if the element's indeterminate IDL attribute is set to true. The indeterminate IDL attribute only gives the appearance of a third state.

The input activation behavior is to run the following steps:

Constraint validation: If the element is required and its checkedness is false, then the element is suffering from being missing.

input . indeterminate [ = value ] When set, overrides the rendering of checkbox controls so that the current value is not visible.

4.10.5.1.16 Radio Button state ( type=radio )

✔ MDN Element/input/radio Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Radio Button state, the rules in this section apply.

The input element represents a control that, when used in conjunction with other input elements, forms a radio button group in which only one control can have its checkedness state set to true. If the element's checkedness state is true, the control represents the selected control in the group, and if it is false, it indicates a control in the group that is not selected.

The radio button group that contains an input element a also contains all the other input elements b that fulfill all of the following conditions:

The input element b 's type attribute is in the Radio Button state.

element 's attribute is in the Radio Button state. Either a and b have the same form owner, or they both have no form owner.

and have the same form owner, or they both have no form owner. Both a and b are in the same tree.

and are in the same tree. They both have a name attribute, their name attributes are not empty, and the value of a 's name attribute equals the value of b 's name attribute.

A tree must not contain an input element whose radio button group contains only that element.

When any of the following phenomena occur, if the element's checkedness state is true after the occurrence, the checkedness state of all the other elements in the same radio button group must be set to false:

The input activation behavior is to run the following steps:

Constraint validation: If an element in the radio button group is required, and all of the input elements in the radio button group have a checkedness that is false, then the element is suffering from being missing.

The following example, for some reason, has specified that puppers are both required and disabled: < form > < p >< label >< input type = "radio" name = "dog-type" value = "pupper" required disabled > Pupper </ label > < p >< label >< input type = "radio" name = "dog-type" value = "doggo" > Doggo </ label > < p >< button > Make your choice </ button > </ form > If the user tries to submit this form without first selecting "Doggo", then both input elements will be suffering from being missing, since an element in the radio button group is required (viz. the first element), and both of the elements in the radio button group have a false checkedness. On the other hand, if the user selects "Doggo" and then submits the form, then neither input element will be suffering from being missing, since while one of them is required, not all of them have a false checkedness.

If none of the radio buttons in a radio button group are checked, then they will all be initially unchecked in the interface, until such time as one of them is checked (either by the user or by script).

4.10.5.1.17 File Upload state ( type=file )

✔ MDN Element/input/file Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera 11+ Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android 11+

When an input element's type attribute is in the File Upload state, the rules in this section apply.

✔ MDN FileList Support in all current engines. Firefox 3+ Safari 4+ Chrome 1+ Opera 11.1+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android 4+ Safari iOS 3.2+ Chrome Android 18+ WebView Android 1+ Samsung Internet 1.0+ Opera Android 11.1+

The input element represents a list of selected files , each file consisting of a file name, a file type, and a file body (the contents of the file).

File names must not contain path components, even in the case that a user has selected an entire directory hierarchy or multiple files with the same name from different directories. Path components , for the purposes of the File Upload state, are those parts of file names that are separated by U+005C REVERSE SOLIDUS character (\) characters.

Unless the multiple attribute is set, there must be no more than one file in the list of selected files.

The element's input activation behavior is to run the following steps:

If the algorithm is invoked when the element's Window object does not have transient activation, then return without doing anything else. Run these steps in parallel: Optionally, wait until any prior execution of this algorithm has terminated. Display a prompt to the user requesting that the user specify some files. If the multiple attribute is not set, there must be no more than one file selected; otherwise, any number may be selected. Files can be from the filesystem or created on the fly, e.g., a picture taken from a camera connected to the user's device. Wait for the user to have made their selection. for the input element.

If the element is mutable, the user agent should allow the user to change the files on the list in other ways also, e.g., adding or removing files by drag-and-drop. When the user does so, the user agent must for the element.

If the element is not mutable, the user agent must not allow the user to change the element's selection.

To for an element element :

Constraint validation: If the element is required and the list of selected files is empty, then the element is suffering from being missing.

✔ MDN Element/input#attr-accept Support in all current engines. Firefox 37+ Safari 11.1+ Chrome 26+ Opera 15+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android 37+ Safari iOS 11.3+ Chrome Android 26+ WebView Android 4.4+ Samsung Internet 1.5+ Opera Android 15+ caniuse.com table

The accept attribute may be specified to provide user agents with a hint of what file types will be accepted.

If specified, the attribute must consist of a set of comma-separated tokens, each of which must be an ASCII case-insensitive match for one of the following:

The string " audio/* " Indicates that sound files are accepted. The string " video/* " Indicates that video files are accepted. The string " image/* " Indicates that image files are accepted. A valid MIME type string with no parameters Indicates that files of the specified type are accepted. A string whose first character is a U+002E FULL STOP character (.) Indicates that files with the specified file extension are accepted.

The tokens must not be ASCII case-insensitive matches for any of the other tokens (i.e. duplicates are not allowed). To obtain the list of tokens from the attribute, the user agent must split the attribute value on commas.

User agents may use the value of this attribute to display a more appropriate user interface than a generic file picker. For instance, given the value image/* , a user agent could offer the user the option of using a local camera or selecting a photograph from their photo collection; given the value audio/* , a user agent could offer the user the option of recording a clip using a headset microphone.

User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.

Authors are encouraged to specify both any MIME types and any corresponding extensions when looking for data in a specific format.

For example, consider an application that converts Microsoft Word documents to Open Document Format files. Since Microsoft Word documents are described with a wide variety of MIME types and extensions, the site can list several, as follows: < input type = "file" accept = ".doc,.docx,.xml,application/msword,application/vnd.openxmlformats-officedocument.wordprocessingml.document" > On platforms that only use file extensions to describe file types, the extensions listed here can be used to filter the allowed documents, while the MIME types can be used with the system's type registration table (mapping MIME types to extensions used by the system), if any, to determine any other extensions to allow. Similarly, on a system that does not have file names or extensions but labels documents with MIME types internally, the MIME types can be used to pick the allowed files, while the extensions can be used if the system has an extension registration table that maps known extensions to MIME types used by the system.

Extensions tend to be ambiguous (e.g. there are an untold number of formats that use the " .dat " extension, and users can typically quite easily rename their files to have a " .doc " extension even if they are not Microsoft Word documents), and MIME types tend to be unreliable (e.g. many formats have no formally registered types, and many formats are in practice labeled using a number of different MIME types). Authors are reminded that, as usual, data received from a client should be treated with caution, as it may not be in an expected format even if the user is not hostile and the user agent fully obeyed the accept attribute's requirements.

For historical reasons, the value IDL attribute prefixes the file name with the string " C:\fakepath\ ". Some legacy user agents actually included the full path (which was a security vulnerability). As a result of this, obtaining the file name from the value IDL attribute in a backwards-compatible way is non-trivial. The following function extracts the file name in a suitably compatible manner: function extractFilename ( path ) { if ( path . substr ( 0 , 12 ) == "C:\\fakepath\\" ) return path . substr ( 12 ); // modern browser var x ; x = path . lastIndexOf ( '/' ); if ( x >= 0 ) // Unix-based path return path . substr ( x + 1 ); x = path . lastIndexOf ( '\\' ); if ( x >= 0 ) // Windows-based path return path . substr ( x + 1 ); return path ; // just the file name } This can be used as follows: < p >< input type = file name = image onchange = "updateFilename(this.value)" ></ p > < p > The name of the file you picked is: < span id = "filename" > (none) </ span ></ p > < script > function updateFilename ( path ) { var name = extractFilename ( path ); document . getElementById ( 'filename' ). textContent = name ; } </ script >

4.10.5.1.18 Submit Button state ( type=submit )

✔ MDN Element/input/submit Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Submit Button state, the rules in this section apply.

The input element represents a button that, when activated, submits the form. If the element has a value attribute, the button's label must be the value of that attribute; otherwise, it must be an implementation-defined string that means "Submit" or some such. The element is a button, specifically a submit button.

Since the default label is implementation-defined, and the width of the button typically depends on the button's label, the button's width can leak a few bits of fingerprintable information. These bits are likely to be strongly correlated to the identity of the user agent and the user's locale.

The element's input activation behavior is as follows: if the element has a form owner, and the element's node document is fully active, submit the form owner from the input element; otherwise, do nothing.

The formaction , formenctype , formmethod , , and formtarget attributes are attributes for form submission.

The attribute can be used to make submit buttons that do not trigger the constraint validation.

4.10.5.1.19 Image Button state ( type=image )

✔ MDN Element/input/image Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android ? WebView Android Yes Samsung Internet ? Opera Android Yes

When an input element's type attribute is in the Image Button state, the rules in this section apply.

The input element represents either an image from which a user can select a coordinate and submit the form, or alternatively a button from which the user can submit the form. The element is a button, specifically a submit button.

The coordinate is sent to the server during form submission by sending two entries for the element, derived from the name of the control but with " .x " and " .y " appended to the name with the x and y components of the coordinate respectively.

The image is given by the src attribute. The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted.

When any of the these events occur

the input element's type attribute is first set to the Image Button state (possibly when the element is first created), and the src attribute is present

element's attribute is first set to the Image Button state (possibly when the element is first created), and the attribute is present the input element's type attribute is changed back to the Image Button state, and the src attribute is present, and its value has changed since the last time the type attribute was in the Image Button state

element's attribute is changed back to the Image Button state, and the attribute is present, and its value has changed since the last time the attribute was in the Image Button state the input element's type attribute is in the Image Button state, and the src attribute is set or changed

then unless the user agent cannot support images, or its support for images has been disabled, or the user agent only fetches images on demand, or the src attribute's value is the empty string, the user agent must parse the value of the src attribute value, relative to the element's node document, and if that is successful, then:

Fetching the image must delay the load event of the element's node document until the task that is queued by the networking task source once the resource has been fetched (defined below) has been run.

If the image was successfully obtained, with no network errors, and the image's type is a supported image type, and the image is a valid image of that type, then the image is said to be available . If this is true before the image is completely downloaded, each task that is queued by the networking task source while the image is being fetched must update the presentation of the image appropriately.

The user agent should apply the image sniffing rules to determine the type of the image, with the image's associated Content-Type headers giving the official type . If these rules are not applied, then the type of the image must be the type given by the image's associated Content-Type headers.

User agents must not support non-image resources with the input element. User agents must not run executable code embedded in the image resource. User agents must only display the first page of a multipage resource. User agents must not allow the resource to act in an interactive fashion, but should honor any animation in the resource.

The task that is queued by the networking task source once the resource has been fetched, must, if the download was successful and the image is available, queue an element task on the user interaction task source given the input element to fire an event named load at the input element; and otherwise, if the fetching process fails without a response from the remote server, or completes but the image is not a valid or supported image, queue an element task on the user interaction task source given the input element to fire an event named error on the input element.

The alt attribute provides the textual label for the button for users and user agents who cannot use the image. The alt attribute must be present, and must contain a non-empty string giving the label that would be appropriate for an equivalent button if the image was unavailable.

The input element supports dimension attributes.

If the src attribute is set, and the image is available and the user agent is configured to display that image, then: The element represents a control for selecting a coordinate from the image specified by the src attribute; if the element is mutable, the user agent should allow the user to select this coordinate, and the element's input activation behavior is as follows: if the element has a form owner, and the element's node document is fully active, take the user's selected coordinate, and submit the input element's form owner from the input element. If the user activates the control without explicitly selecting a coordinate, then the coordinate (0,0) must be assumed.

Otherwise, the element represents a submit button whose label is given by the value of the alt attribute; the element's input activation behavior is as follows: if the element has a form owner, and the element's node document is fully active, set the selected coordinate to (0,0), and submit the input element's form owner from the input element.

In either case, if the element has no form owner or the element's node document is not fully active, then its input activation behavior must be to do nothing..

The selected coordinate must consist of an x -component and a y -component. The coordinates represent the position relative to the edge of the image, with the coordinate space having the positive x direction to the right, and the positive y direction downwards.

The x -component must be a valid integer representing a number x in the range −( border left + padding left ) ≤ x ≤ width + border right + padding right , where width is the rendered width of the image, border left is the width of the border on the left of the image, padding left is the width of the padding on the left of the image, border right is the width of the border on the right of the image, and padding right is the width of the padding on the right of the image, with all dimensions given in CSS pixels.

The y -component must be a valid integer representing a number y in the range −( border top + padding top ) ≤ y ≤ height + border bottom + padding bottom , where height is the rendered height of the image, border top is the width of the border above the image, padding top is the width of the padding above the image, border bottom is the width of the border below the image, and padding bottom is the width of the padding below the image, with all dimensions given in CSS pixels.

Where a border or padding is missing, its width is zero CSS pixels.

The formaction , formenctype , formmethod , , and formtarget attributes are attributes for form submission.

image . width [ = value ] image . height [ = value ] These attributes return the actual rendered dimensions of the image, or zero if the dimensions are not known. They can be set, to change the corresponding content attributes.

Many aspects of this state's behavior are similar to the behavior of the img element. Readers are encouraged to read that section, where many of the same requirements are described in more detail.

Take the following form: < form action = "process.cgi" > < input type = image src = map.png name = where alt = "Show location list" > </ form > If the user clicked on the image at coordinate (127,40) then the URL used to submit the form would be " process.cgi?where.x=127&where.y=40 ". (In this example, it's assumed that for users who don't see the map, and who instead just see a button labeled "Show location list", clicking the button will cause the server to show a list of locations to pick from instead of the map.)

4.10.5.1.20 Reset Button state ( type=reset )

✔ MDN Element/input/reset Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes

When an input element's type attribute is in the Reset Button state, the rules in this section apply.

The input element represents a button that, when activated, resets the form. If the element has a value attribute, the button's label must be the value of that attribute; otherwise, it must be an implementation-defined string that means "Reset" or some such. The element is a button.

Since the default label is implementation-defined, and the width of the button typically depends on the button's label, the button's width can leak a few bits of fingerprintable information. These bits are likely to be strongly correlated to the identity of the user agent and the user's locale.

The element's input activation behavior, if the element has a form owner and the element's node document is fully active, is to reset the form owner; otherwise, it is to do nothing.

Constraint validation: The element is barred from constraint validation.

4.10.5.1.21 Button state ( type=button )

✔ MDN Element/input/button Support in all current engines. Firefox 1+ Safari 1+ Chrome 1+ Opera Yes Edge 79+ Edge (Legacy) 12+ Internet Explorer Yes Firefox Android 4+ Safari iOS Yes Chrome Android 18+ WebView Android Yes Samsung Internet 1.0+ Opera Android Yes

When an input element's type attribute is in the Button state, the rules in this section apply.

The input element represents a button with no default behavior. A label for the button must be provided in the value attribute, though it may be the empty string. If the element has a value attribute, the button's label must be the value of that attribute; otherwise, it must be the empty string. The element is a button.

The element has no input activation behavior.

Constraint validation: The element is barred from constraint validation.

4.10.5.2 Implementation notes regarding localization of form controls

This section is non-normative.

The formats shown to the user in date, time, and number controls is independent of the format used for form submission.

Browsers are encouraged to use user interfaces that present dates, times, and numbers according to the conventions of either the locale implied by the input element's language or the user's preferred locale. Using the page's locale will ensure consistency with page-provided data.

For example, it would be confusing to users if an American English page claimed that a Cirque De Soleil show was going to be showing on 02/03, but their browser, configured to use the British English locale, only showed the date 03/02 in the ticket purchase date picker. Using the page's locale would at least ensure that the date was presented in the same format everywhere. (There's still a risk that the user would end up arriving a month late, of course, but there's only so much that can be done about such cultural differences...)

4.10.5.3 Common input element attributes

These attributes only apply to an input element if its type attribute is in a state whose definition declares that the attribute applies. When an attribute doesn't apply to an input element, user agents must ignore the attribute, regardless of the requirements and definitions below.

4.10.5.3.1 The maxlength and minlength attributes

✔ MDN Element/input#attr-maxlength Support in all current engines. Firefox 4+ Safari 5.1+ Chrome 4+ Opera 15+ Edge 79+ Edge (Legacy) 12+ Internet Explorer 10+ Firefox Android 5+ Safari iOS 9+ Chrome Android 18+ WebView Android 4.4+ Samsung Internet 1.5+ Opera Android 15+ caniuse.com table

The maxlength attribute, when it applies, is a form control maxlength attribute.

✔ MDN Element/input#attr-minlength Support in all current engines. Firefox 51+ Safari 10.1+ Chrome 40+ Opera 27+ Edge 79+ Edge (Legacy) 17+ Internet Explorer No Firefox Android 51+ Safari iOS 10.3+ Chrome Android 40+ WebView Android 40+ Samsung Internet 4.0+ Opera Android 27+ caniuse.com table

The minlength attribute, when it applies, is a form control minlength attribute.

If the input element has a maximum allowed value length, then the length of the value of the element's value attribute must be equal to or less than the element's maximum allowed value length.

The following extract shows how a messaging client's text entry could be arbitrarily restricted to a fixed number of characters, thus forcing any conversation through this medium to be terse and discouraging intelligent discourse. < label > What are you doing? < input name = status maxlength = 140 ></ label >

Here, a password is given a minimum length: < p >< label > Username: < input name = u required ></ label > < p >< label > Password: < input name = p required minlength = 12 ></ label >

4.10.5.3.2 The size attribute

The size attribute gives the number of characters that, in a visual rendering, the user agent is to allow the user to see while editing the element's value.

The size attribute, if specified, must have a value that is a valid non-negative integer greater than zero.

If the attribute is present, then its value must be parsed using the rules for parsing non-negative integers, and if the result is a number greater than zero, then the user agent should ensure that at least that many characters are visible.

The size IDL attribute is limited to only non-negative numbers greater than zero and has a default value of 20.

4.10.5.3.3 The readonly attribute

✔ MDN Attributes/readonly Support in all current engines. Firefox Yes Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

The readonly attribute is a boolean attribute that controls whether or not the user can edit the form control. When specified, the element is not mutable.

Constraint validation: If the readonly attribute is specified on an input element, the element is barred from constraint validation.

The difference between disabled and readonly is that read-only controls can still function, whereas disabled controls generally do not function as controls until they are enabled. This is spelled out in more detail elsewhere in this specification with normative requirements that refer to the disabled concept (for example, the element's activation behavior, whether or not it is a focusable area, or when constructing the entry list). Any other behavior related to user interaction with disabled controls, such as whether text can be selected or copied, is not defined in this standard. Only text controls can be made read-only, since for other controls (such as checkboxes and buttons) there is no useful distinction between being read-only and being disabled, so the readonly attribute does not apply.

In the following example, the existing product identifiers cannot be modified, but they are still displayed as part of the form, for consistency with the row representing a new product (where the identifier is not yet filled in). < form action = "products.cgi" method = "post" enctype = "multipart/form-data" > < table > < tr > < th > Product ID < th > Product name < th > Price < th > Action < tr > < td > < input readonly = "readonly" name = "1.pid" value = "H412" > < td > < input required = "required" name = "1.pname" value = "Floor lamp Ulke" > < td > $ < input required = "required" type = "number" min = "0" step = "0.01" name = "1.pprice" value = "49.99" > < td > < button formnovalidate = "formnovalidate" name = "action" value = "delete:1" > Delete </ button > < tr > < td > < input readonly = "readonly" name = "2.pid" value = "FG28" > < td > < input required = "required" name = "2.pname" value = "Table lamp Ulke" > < td > $ < input required = "required" type = "number" min = "0" step = "0.01" name = "2.pprice" value = "24.99" > < td > < button formnovalidate = "formnovalidate" name = "action" value = "delete:2" > Delete </ button > < tr > < td > < input required = "required" name = "3.pid" value = "" pattern = "[A-Z0-9]+" > < td > < input required = "required" name = "3.pname" value = "" > < td > $ < input required = "required" type = "number" min = "0" step = "0.01" name = "3.pprice" value = "" > < td > < button formnovalidate = "formnovalidate" name = "action" value = "delete:3" > Delete </ button > </ table > < p > < button formnovalidate = "formnovalidate" name = "action" value = "add" > Add </ button > </ p > < p > < button name = "action" value = "update" > Save </ button > </ p > </ form >

4.10.5.3.4 The required attribute

The required attribute is a boolean attribute. When specified, the element is required .

Constraint validation: If the element is required, and its value IDL attribute applies and is in the mode value, and the element is mutable, and the element's value is the empty string, then the element is suffering from being missing.

The following form has two required fields, one for an email address and one for a password. It also has a third field that is only considered valid if the user types the same password in the password field and this third field. < h1 > Create new account </ h1 > < form action = "/newaccount" method = post oninput = "up2.setCustomValidity(up2.value != up.value ? 'Passwords do not match.' : '')" > < p > < label for = "username" > Email address: </ label > < input id = "username" type = email required name = un > < p > < label for = "password1" > Password: </ label > < input id = "password1" type = password required name = up > < p > < label for = "password2" > Confirm password: </ label > < input id = "password2" type = password name = up2 > < p > < input type = submit value = "Create account" > </ form >

For radio buttons, the required attribute is satisfied if any of the radio buttons in the group is selected. Thus, in the following example, any of the radio buttons can be checked, not just the one marked as required: < fieldset > < legend > Did the movie pass the Bechdel test? </ legend > < p >< label >< input type = "radio" name = "bechdel" value = "no-characters" > No, there are not even two female characters in the movie. </ label > < p >< label >< input type = "radio" name = "bechdel" value = "no-names" > No, the female characters never talk to each other. </ label > < p >< label >< input type = "radio" name = "bechdel" value = "no-topic" > No, when female characters talk to each other it's always about a male character. </ label > < p >< label >< input type = "radio" name = "bechdel" value = "yes" required > Yes. </ label > < p >< label >< input type = "radio" name = "bechdel" value = "unknown" > I don't know. </ label > </ fieldset > To avoid confusion as to whether a radio button group is required or not, authors are encouraged to specify the attribute on all the radio buttons in a group. Indeed, in general, authors are encouraged to avoid having radio button groups that do not have any initially checked controls in the first place, as this is a state that the user cannot return to, and is therefore generally considered a poor user interface.

4.10.5.3.5 The multiple attribute

✔ MDN HTMLInputElement/multiple Support in all current engines. Firefox 3.6+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer ? Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table Element/input#attr-multiple Support in all current engines. Firefox 3.6+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer ? Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

The multiple attribute is a boolean attribute that indicates whether the user is to be allowed to specify more than one value.

The following extract shows how an email client's "To" field could accept multiple email addresses. < label > To: < input type = email multiple name = to ></ label > If the user had, amongst many friends in their user contacts database, two friends "Spider-Man" (with address "spider@parker.example.net") and "Scarlet Witch" (with address "scarlet@avengers.example.net"), then, after the user has typed " s ", the user agent might suggest these two email addresses to the user. The page could also link in the user's contacts database from the site: < label > To: < input type = email multiple name = to list = contacts ></ label > ... < datalist id = "contacts" > < option value = "hedral@damowmow.com" > < option value = "pillar@example.com" > < option value = "astrophy@cute.example" > < option value = "astronomy@science.example.org" > </ datalist > Suppose the user had entered " bob@example.net " into this text control, and then started typing a second email address starting with " s ". The user agent might show both the two friends mentioned earlier, as well as the "astrophy" and "astronomy" values given in the datalist element.

The following extract shows how an email client's "Attachments" field could accept multiple files for upload. < label > Attachments: < input type = file multiple name = att ></ label >

4.10.5.3.6 The pattern attribute

✔ MDN Attributes/pattern Support in all current engines. Firefox 4+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

The pattern attribute specifies a regular expression against which the control's value, or, when the multiple attribute applies and is set, the control's values, are to be checked.

If specified, the attribute's value must match the JavaScript Pattern [+U, +N] production.

The compiled pattern regular expression of an input element, if it exists, is a JavaScript RegExp object. It is determined as follows:

If the element does not have a pattern attribute specified, then return nothing. The element has no compiled pattern regular expression. Let pattern be the value of the pattern attribute of the element. Let regexpCompletion be RegExpCreate( pattern , " u "). [JAVASCRIPT] If regexpCompletion is an abrupt completion, then return nothing. The element has no compiled pattern regular expression. User agents are encouraged to log this error in a developer console, to aid debugging. Let anchoredPattern be the string " ^(?: ", followed by pattern , followed by " )$ ". Return ! RegExpCreate( anchoredPattern , " u ").

The reasoning behind these steps, instead of just using the value of the pattern attribute directly, is twofold. First, we want to ensure that when matched against a string, the regular expression's start is anchored to the start of the string and its end to the end of the string. Second, we want to ensure that the regular expression is valid in standalone form, instead of only becoming valid after being surrounded by the " ^(?: " and " )$ " anchors.

A RegExp object regexp matches a string input , if ! RegExpBuiltinExec( regexp , input ) is not null.

Constraint validation: If the element's value is not the empty string, and either the element's multiple attribute is not specified or it does not apply to the input element given its type attribute's current state, and the element has a compiled pattern regular expression but that regular expression does not match the element's value, then the element is suffering from a pattern mismatch.

Constraint validation: If the element's value is not the empty string, and the element's multiple attribute is specified and applies to the input element, and the element has a compiled pattern regular expression but that regular expression does not match each of the element's values, then the element is suffering from a pattern mismatch.

When an input element has a pattern attribute specified, authors should include a title attribute to give a description of the pattern. User agents may use the contents of this attribute, if it is present, when informing the user that the pattern is not matched, or at any other suitable time, such as in a tooltip or read out by assistive technology when the control gains focus.

For example, the following snippet: < label > Part number: < input pattern = "[0-9][A-Z]{3}" name = "part" title = "A part number is a digit followed by three uppercase letters." /> </ label > ...could cause the UA to display an alert such as: A part number is a digit followed by three uppercase letters. You cannot submit this form when the field is incorrect.

When a control has a pattern attribute, the title attribute, if used, must describe the pattern. Additional information could also be included, so long as it assists the user in filling in the control. Otherwise, assistive technology would be impaired.

For instance, if the title attribute contained the caption of the control, assistive technology could end up saying something like The text you have entered does not match the required pattern. Birthday , which is not useful.

UAs may still show the title in non-error situations (for example, as a tooltip when hovering over the control), so authors should be careful not to word title s as if an error has necessarily occurred.

4.10.5.3.7 The min and max attributes

Some form controls can have explicit constraints applied limiting the allowed range of values that the user can provide. Normally, such a range would be linear and continuous. A form control can have a periodic domain , however, in which case the form control's broadest possible range is finite, and authors can specify explicit ranges within it that span the boundaries.

Specifically, the broadest range of a type=time control is midnight to midnight (24 hours), and authors can set both continuous linear ranges (such as 9pm to 11pm) and discontinuous ranges spanning midnight (such as 11pm to 1am).

The min and max attributes indicate the allowed range of values for the element.

Their syntax is defined by the section that defines the type attribute's current state.

If the element has a min attribute, and the result of applying the algorithm to convert a string to a number to the value of the min attribute is a number, then that number is the element's minimum ; otherwise, if the type attribute's current state defines a default minimum , then that is the minimum; otherwise, the element has no minimum.

The min attribute also defines the step base.

If the element has a max attribute, and the result of applying the algorithm to convert a string to a number to the value of the max attribute is a number, then that number is the element's maximum ; otherwise, if the type attribute's current state defines a default maximum , then that is the maximum; otherwise, the element has no maximum.

If the element does not have a periodic domain, the max attribute's value (the maximum) must not be less than the min attribute's value (its minimum).

If an element that does not have a periodic domain has a maximum that is less than its minimum, then so long as the element has a value, it will either be suffering from an underflow or suffering from an overflow.

An element has a reversed range if it has a periodic domain and its maximum is less than its minimum.

An element has range limitations if it has a defined minimum or a defined maximum.

Constraint validation: When the element has a minimum and does not have a reversed range, and the result of applying the algorithm to convert a string to a number to the string given by the element's value is a number, and the number obtained from that algorithm is less than the minimum, the element is suffering from an underflow.

Constraint validation: When the element has a maximum and does not have a reversed range, and the result of applying the algorithm to convert a string to a number to the string given by the element's value is a number, and the number obtained from that algorithm is more than the maximum, the element is suffering from an overflow.

Constraint validation: When an element has a reversed range, and the result of applying the algorithm to convert a string to a number to the string given by the element's value is a number, and the number obtained from that algorithm is more than the maximum and less than the minimum, the element is simultaneously suffering from an underflow and suffering from an overflow.

The following date control limits input to dates that are before the 1980s: < input name = bday type = date max = "1979-12-31" >

The following number control limits input to whole numbers greater than zero: < input name = quantity required = "" type = "number" min = "1" value = "1" >

The following time control limits input to those minutes that occur between 9pm and 6am, defaulting to midnight: < input name = "sleepStart" type = time min = "21:00" max = "06:00" step = "60" value = "00:00" >

4.10.5.3.8 The step attribute

The step attribute indicates the granularity that is expected (and required) of the value or values, by limiting the allowed values. The section that defines the type attribute's current state also defines the default step , the step scale factor , and in some cases the default step base , which are used in processing the attribute as described below.

The step attribute, if specified, must either have a value that is a valid floating-point number that parses to a number that is greater than zero, or must have a value that is an ASCII case-insensitive match for the string " any ".

The attribute provides the allowed value step for the element, as follows:

The step base is the value returned by the following algorithm:

Constraint validation: When the element has an allowed value step, and the result of applying the algorithm to convert a string to a number to the string given by the element's value is a number, and that number subtracted from the step base is not an integral multiple of the allowed value step, the element is suffering from a step mismatch.

The following range control only accepts values in the range 0..1, and allows 256 steps in that range: < input name = opacity type = range min = 0 max = 1 step = 0.00392156863 >

The following control allows any time in the day to be selected, with any accuracy (e.g. thousandth-of-a-second accuracy or more): < input name = favtime type = time step = any > Normally, time controls are limited to an accuracy of one minute.

4.10.5.3.9 The list attribute

The list attribute is used to identify an element that lists predefined options suggested to the user.

If present, its value must be the ID of a datalist element in the same tree.

The suggestions source element is the first element in the tree in tree order to have an ID equal to the value of the list attribute, if that element is a datalist element. If there is no list attribute, or if there is no element with that ID, or if the first element with that ID is not a datalist element, then there is no suggestions source element.

If there is a suggestions source element, then, when the user agent is allowing the user to edit the input element's value, the user agent should offer the suggestions represented by the suggestions source element to the user in a manner suitable for the type of control used. If appropriate, the user agent should use the suggestion's label and value to identify the suggestion to the user.

User agents are encouraged to filter the suggestions represented by the suggestions source element when the number of suggestions is large, including only the most relevant ones (e.g. based on the user's input so far). No precise threshold is defined, but capping the list at four to seven values is reasonable. If filtering based on the user's input, user agents should use substring matching against both the suggestions' label and value.

This text field allows you to choose a type of JavaScript function. < input type = "text" list = "function-types" > < datalist id = "function-types" > < option value = "function" > function </ option > < option value = "async function" > async function </ option > < option value = "function*" > generator function </ option > < option value = "=>" > arrow function </ option > < option value = "async =>" > async arrow function </ option > < option value = "async function*" > async generator function </ option > </ datalist > For user agents that follow the above suggestions, both the label and value would be shown: Then, typing " arrow " or " => " would filter the list to the entries with labels "arrow function" and "async arrow function". Typing " generator " or " * " would filter the list to the entries with labels "generator function" and "async generator function".

As always, user agents are free to make user interface decisions which are appropriate for their particular requirements and for the user's particular circumstances. However, this has historically been an area of confusion for implementers, web developers, and users alike, so we've given some "should" suggestions above.

How user selections of suggestions are handled depends on whether the element is a control accepting a single value only, or whether it accepts multiple values:

If the element does not have a multiple attribute specified or if the multiple attribute does not apply When the user selects a suggestion, the input element's value must be set to the selected suggestion's value, as if the user had written that value themself. If the element's type attribute is in the Email state and the element has a multiple attribute specified When the user selects a suggestion, the user agent must either add a new entry to the input element's values, whose value is the selected suggestion's value, or change an existing entry in the input element's values to have the value given by the selected suggestion's value, as if the user had themself added an entry with that value, or edited an existing entry to be that value. Which behavior is to be applied depends on the user interface in an implementation-defined manner.

If the list attribute does not apply, there is no suggestions source element.

This URL field offers some suggestions. < label > Homepage: < input name = hp type = url list = hpurls ></ label > < datalist id = hpurls > < option value = "https://www.google.com/" label = "Google" > < option value = "https://www.reddit.com/" label = "Reddit" > </ datalist > Other URLs from the user's history might show also; this is up to the user agent.

This example demonstrates how to design a form that uses the autocompletion list feature while still degrading usefully in legacy user agents. If the autocompletion list is merely an aid, and is not important to the content, then simply using a datalist element with children option elements is enough. To prevent the values from being rendered in legacy user agents, they need to be placed inside the value attribute instead of inline. < p > < label > Enter a breed: < input type = "text" name = "breed" list = "breeds" > < datalist id = "breeds" > < option value = "Abyssinian" > < option value = "Alpaca" > <!-- ... --> </ datalist > </ label > </ p > However, if the values need to be shown in legacy UAs, then fallback content can be placed inside the datalist element, as follows: < p > < label > Enter a breed: < input type = "text" name = "breed" list = "breeds" > </ label > < datalist id = "breeds" > < label > or select one from the list: < select name = "breed" > < option value = "" > (none selected) < option > Abyssinian < option > Alpaca <!-- ... --> </ select > </ label > </ datalist > </ p > The fallback content will only be shown in UAs that don't support datalist . The options, on the other hand, will be detected by all UAs, even though they are not children of the datalist element. Note that if an option element used in a datalist is selected , it will be selected by default by legacy UAs (because it affects the select ), but it will not have any effect on the input element in UAs that support datalist .

4.10.5.3.10 The placeholder attribute

✔ MDN Element/input#attr-placeholder Support in all current engines. Firefox 4+ Safari Yes Chrome Yes Opera Yes Edge Yes Edge (Legacy) 12+ Internet Explorer Yes Firefox Android Yes Safari iOS Yes Chrome Android Yes WebView Android Yes Samsung Internet Yes Opera Android Yes caniuse.com table

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value. A hint could be a sample value or a brief description of the expected format. The attribute, if specified, must have a value that contains no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters.

The placeholder attribute should not be used as an alternative to a label . For a longer hint or other advisory text, the title attribute is more appropriate.

These mechanisms are very similar but subtly different: the hint given by the control's label is shown at all ti