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 with the following keywords and states:
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 algorithm to convert a string to a
Date object, and an algorithm to
convert a Date object to a string, which are used by max, min, step, valueAsDate,
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 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.
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.
The readonly attribute can also in some
cases (e.g. for the Date state, but not the Checkbox state) stop an input element from
being mutable.
The input element can support a picker. A
picker is a user interface element that allows the end user to choose a value. Whether an
input element supports a picker depends on the type attribute state and implementation-defined
behavior. An input element must support a picker when its type attribute is in the File
Upload state.
As of the time of this writing, typical browser implementations show such picker UI for:
Recall that an element’s activation behavior runs for both
user-initiated activations and for synthetic activations (e.g., via el.click()). User agents might also have behaviors for a given control — not
specified here — that are triggered only by true user-initiated activations. A common choice is to
show the picker, if applicable, for the control. In contrast, the input
activation behavior only shows pickers for the special historical cases of the File Upload and Color states.
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.
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.
When an input element’s type attribute
changes state, the user agent must run the following steps:
If the previous state of the element’s type attribute
put the value IDL attribute in the value mode, and the element’s value is not the empty string, and the new state of the element’s
type attribute puts the value IDL attribute in either the default mode or the default/on mode, then set the element’s value content attribute to the element’s value.
Otherwise, if the previous state of the element’s type attribute put the value
IDL attribute in any mode other than the value mode, and the
new state of the element’s type attribute puts the value IDL attribute in the value mode, then 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 set the control’s dirty value flag to
false.
Otherwise, if the previous state of the element’s type attribute put the value IDL attribute in any mode other than the filename mode, and the new state of the element’s type attribute puts the value IDL attribute in the filename mode, then set the value of the element to the empty string.
Update the element’s rendering and behavior to the new state’s.
Signal a type change for the element. (The Radio Button state uses this, in particular.)
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.
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.
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:
Set the element’s dir attribute to “ltr” if the user selected a left-to-right writing direction, and
“rtl” if the user selected a right-to-left writing
direction.
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.
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.
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 validabsolute URL, but may also or instead
automatically escape characters entered by the user so that the value is always a validabsolute 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.
<inputtype="url"name="location"list="urls"><datalistid="urls"><optionlabel="MIME: Format of Internet Message Bodies"value="https://www.rfc-editor.org/rfc/rfc2045"><optionlabel="HTML"value="https://html.spec.whatwg.org/"><optionlabel="DOM"value="https://dom.spec.whatwg.org/"><optionlabel="Fullscreen"value="https://fullscreen.spec.whatwg.org/"><optionlabel="Media Session"value="https://mediasession.spec.whatwg.org/"><optionlabel="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.
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 not specified on the
element
The input element represents a control for editing an email
address given in the element’s value.
If the element is mutable, the user agent should allow the
user to change the email address represented by its value. User agents may allow the user to set the value to a string that is not a valid email
address. The user agent should act in a manner consistent with expecting the user to
provide a single email address. 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. User agents may transform the value for display and editing; in particular, user agents should
convert punycode in the domain labels of the value to IDN in the display and
vice versa.
Constraint validation: While the user interface is representing input that
the user agent cannot convert to punycode, the control is suffering from bad
input.
The value attribute, if specified and not empty, must
have a value that is a single valid email address.
When the multiple attribute is specified on
the element
The input element represents a control for adding, removing, and
editing the email addresses given in the element’s values.
If the element is mutable, the user agent should allow the
user to add, remove, and edit the email addresses represented by its values. User agents may allow the user to set any
individual value in the list of values to a
string that is not a valid email address, but must not allow users to set any
individual value to a string containing U+002C COMMA (,), U+000A LINE FEED (LF), or U+000D
CARRIAGE RETURN (CR) characters. User agents should allow the user to remove all the addresses
in the element’s values. User agents may
transform the values for display and editing; in
particular, user agents should convert punycode in the domain labels of the value to IDN in the display and vice versa.
Constraint validation: While the user interface describes a situation where
an individual value contains a U+002C COMMA (,) or is representing input that the user agent
cannot convert to punycode, the control is suffering from bad input.
Whenever the user changes the element’s values, the user agent must run the following
steps:
Let latest values be a copy of the element’s values.
Set the element’s value to the result of
concatenating all the values in latest values, separating each value from
the next by a single U+002C COMMA character (,), maintaining the list’s order.
Set the element’s value to the result of
concatenating the element’s values, separating
each value from the next by a single U+002C COMMA character (,), maintaining the list’s
order.
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.
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.
When an input element’s type attribute is in
the Date 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 date.
If the element is mutable, the user agent should allow the
user to change the date represented by its value, as obtained by parsing a
date from it. User agents must not allow the user to set the value to a non-empty string that is not a valid date
string. If the user agent provides a user interface for selecting a date, then the value must be set
to a valid date string representing the user’s selection. User agents should allow
the user to set the value to the empty string.
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 date string.
The step attribute is expressed in days. The step scale factor is 86,400,000
(which converts the days to milliseconds, as used in the other algorithms). The default step is 1 day.
The algorithm to convert a string to a
number, given a string input, is as follows: If parsing a date 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 date, ignoring leap seconds.
The algorithm to convert a number to a
string, given a number input, is as follows: Return a
valid date string that represents the date 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 Date 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 Date 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
select element and input elements with the Number state.
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.
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 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 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.
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 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).
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“).
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.
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 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.
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 input element represents a control for setting the element’s
value to a string representing a local date and time, with no time-zone offset
information.
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 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.
The algorithm to convert a string to a
number, given a string input, is as follows: If parsing a date and time 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 local date and time, ignoring leap seconds.
The following example shows part of a flight booking application. The application uses an
input element with its type attribute set to
datetime-local, and it then interprets the
given date and time in the time zone of the selected airport.
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.
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.
Here is an example of using a numeric input control:
<label>How much do you want to charge? $<inputtype=numbermin=0step=0.01name=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).
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.
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:
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 ignored.
For another example, consider the following markup fragment:
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:
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 the serialization
of a CSS color.
In this state, there is always a CSS color picked, and there is no way for the end
user to set the value to the empty string.
The alpha attribute
is a boolean attribute. If present, it indicates the CSS color’s alpha component can
be manipulated by the end user and does not have to be fully opaque.
The colorspace
attribute indicates the color space of the serialized CSS color. It also hints at the desired user
interface for selecting a CSS color. It is an enumerated attribute with the following
keywords and states:
Keyword
State
Brief description
limited-srgb
Limited sRGB
The CSS color is converted to the ‘srgb’ color space and limited to 8-bits per
component, e.g., “#123456” or “color(srgb 0 1 0 / 0.5)“.
display-p3
Display P3
The CSS color is converted to the ‘display-p3’ color space, e.g., “color(display-p3 1.84 -0.19 0.72 / 0.6)“.
If the element is mutable, the user agent should allow the
user to change the color represented by its value, as
obtained from parsing it. User agents must not
allow the user to set the value to a string that running
update a color well control color for the element would not set it to. If the user
agent provides a user interface for selecting a CSS color, then the value must be set to the result of serializing a color well control color given the element and the
end user’s selection.
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.
When set, overrides the rendering of checkbox
controls so that the current value is not visible.
The following common input element content attributes and IDL attributes apply to the element:
checked, and
required content attributes;
checked and
value IDL attributes.
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:
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 element’s checkedness state is set to true (for
whatever reason).
The element’s name attribute is set, changed, or
removed.
The following example, for some reason, has specified that puppers are both required and disabled:
<form><p><label><inputtype="radio"name="dog-type"value="pupper"requireddisabled> Pupper</label><p><label><inputtype="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 bothinput 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).
The following common input element content attributes and IDL attributes apply to the element:
checked and
required content attributes;
checked and
value IDL attributes.
When an input element’s type attribute is in
the File Upload state, the rules in this section
apply.
The input element represents a list of selected files, each file consisting of a
filename, a file type, and a file body (the contents of the file).
Filenames 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 filenames 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.
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 update the file selection
for the element.
If the element is not mutable, the user agent must not allow
the user to change the element’s selection.
To update the file selection for an element element:
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:
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 filenames 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.
value IDL attribute prefixes
the filename 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 filename from the value IDL attribute in a
backwards-compatible way is non-trivial. The following function extracts the filename in a
suitably compatible manner:
function extractFilename(path){if(path.substr(0,12)=="C:\\fakepath\\")return path.substr(12);// modern browservar x;
x = path.lastIndexOf('/');if(x >=0)// Unix-based pathreturn path.substr(x+1);
x = path.lastIndexOf('\\');if(x >=0)// Windows-based pathreturn path.substr(x+1);return path;// just the filename}
This can be used as follows:
<p><inputtype=filename=imageonchange="updateFilename(this.value)"></p><p>The name of the file you picked is: <spanid="filename">(none)</span></p><script>function updateFilename(path){var name = extractFilename(path);
document.getElementById('filename').textContent = name;}</script>
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 optional value is the value of
the element’s value attribute, if there is one; otherwise
null.
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 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
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
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, run these steps:
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.
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 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.
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. In that case, if the element is mutable, the user agent should allow the user to select this coordinate.
Otherwise, the element represents a submit button whose label is given by the
value of the alt attribute.
If the user activated the control while explicitly selecting a coordinate, then set the
element’s selected coordinate to that
coordinate.
This is only possible under the conditions outlined above, when the element
represents a control for selecting such a coordinate. Even then, the user
might activate the control without explicitly selecting a coordinate.
The element’s selected coordinate
consists of an x-component and a y-component. It is initially (0, 0). The
coordinates represent the position relative to the edge of the element’s 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 −(borderleft+paddingleft) ≤ x ≤ width+borderright+paddingright, where width is the rendered width of the image, borderleft is the width of the border on the left of the image, paddingleft is the width of the padding on the left of the
image, borderright is the width of the border on the right
of the image, and paddingright 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 −(bordertop+paddingtop) ≤ y ≤ height+borderbottom+paddingbottom, where
height is the rendered height of the image, bordertop is the width of the border above the image, paddingtop is the width of the padding above the image, borderbottom is the width of the border below the image, and paddingbottom 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.
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.
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.)
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.
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.
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…)
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.
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? <inputname=statusmaxlength=140></label>
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.
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 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.
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).
<formaction="products.cgi"method="post"enctype="multipart/form-data"><table><tr><th> Product ID <th> Product name <th> Price <th> Action
<tr><td><inputreadonly="readonly"name="1.pid"value="H412"><td><inputrequired="required"name="1.pname"value="Floor lamp Ulke"><td> $<inputrequired="required"type="number"min="0"step="0.01"name="1.pprice"value="49.99"><td><buttonformnovalidate="formnovalidate"name="action"value="delete:1">Delete</button><tr><td><inputreadonly="readonly"name="2.pid"value="FG28"><td><inputrequired="required"name="2.pname"value="Table lamp Ulke"><td> $<inputrequired="required"type="number"min="0"step="0.01"name="2.pprice"value="24.99"><td><buttonformnovalidate="formnovalidate"name="action"value="delete:2">Delete</button><tr><td><inputrequired="required"name="3.pid"value=""pattern="[A-Z0-9]+"><td><inputrequired="required"name="3.pname"value=""><td> $<inputrequired="required"type="number"min="0"step="0.01"name="3.pprice"value=""><td><buttonformnovalidate="formnovalidate"name="action"value="delete:3">Delete</button></table><p><buttonformnovalidate="formnovalidate"name="action"value="add">Add</button></p><p><buttonname="action"value="update">Save</button></p></form>
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><formaction="/newaccount"method=postoninput="up2.setCustomValidity(up2.value != up.value ? 'Passwords do not match.' : '')"><p><labelfor="username">Email address:</label><inputid="username"type=emailrequiredname=un><p><labelfor="password1">Password:</label><inputid="password1"type=passwordrequiredname=up><p><labelfor="password2">Confirm password:</label><inputid="password2"type=passwordname=up2><p><inputtype=submitvalue="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><inputtype="radio"name="bechdel"value="no-characters"> No, there are not even two female characters in the movie. </label><p><label><inputtype="radio"name="bechdel"value="no-names"> No, the female characters never talk to each other. </label><p><label><inputtype="radio"name="bechdel"value="no-topic"> No, when female characters talk to each other it's always about a male character. </label><p><label><inputtype="radio"name="bechdel"value="yes"required> Yes. </label><p><label><inputtype="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.
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:
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.
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[+UnicodeSetsMode, +N] production.
The compiled pattern regular expression of an input element, if it
exists, is a JavaScript RegExp object. It is determined as follows:
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.
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:
<inputpattern="[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
titles as if an error has necessarily occurred.
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.
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.
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 base is the value returned by the following
algorithm:
If the element has a min content attribute, and the
result of applying the algorithm to convert a
string to a number to the value of the min content
attribute is not an error, then return that result.
If the element has a value content attribute, and
the result of applying the algorithm to convert
a string to a number to the value of the value
content attribute is not an error, then return that result.
If a default step base is defined for
this element given its type attribute’s state, then return
it.
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 search within both the label and value
of the suggestions for matches. User agents should consider how input variations affect the
matching process. Unicode normalization should be applied so that different underlying Unicode
code point sequences, caused by different keyboard- or input-specific mechanisms, do not
interfere with the matching process. Case variations should be ignored, which may require
language-specific case mapping. For examples of these, see Character Model for the World
Wide Web: String Matching. User agents may also provide other matching features: for
illustration, a few examples include matching different forms of kana to each other (or to kanji),
ignoring accents, or applying spelling correction. [CHARMODNORM]
This text field allows you to choose a type of JavaScript function.
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:
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.
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:
<inputtype="text"name="breed"list="breeds"><datalistid="breeds"><optionvalue="Abyssinian"><optionvalue="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:
<inputtype="text"name="breed"list="breeds"></label><datalistid="breeds"><label>
or select one from the list:
<selectname="breed"><optionvalue=""> (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 element), but it will not have any effect on the
input element in UAs that support datalist.
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 times; the short hint given in the placeholder attribute is shown before the user enters a
value; and the hint in the title attribute is shown when the user
requests further help.
User agents should present this hint to the user, after having stripped newlines from it, when the element’s value is the empty string, especially if the control is not
focused.
If a user agent normally doesn’t show this hint to the user when the control is
focused, then the user agent should nonetheless show the hint for the control if it
was focused as a result of the autofocus attribute, since
in that case the user will not have had an opportunity to examine the control before focusing
it.
Here is an example of a mail configuration user interface that uses the placeholder attribute:
In situations where the control’s content has one directionality but the placeholder needs to
have a different directionality, Unicode’s bidirectional-algorithm formatting characters can be
used in the attribute value:
The value IDL
attribute allows scripts to manipulate the value of an
input element. The attribute is in one of the following modes, which define its
behavior:
value
On getting, return the current value of the
element.
On getting, if the element has a value content
attribute, return that attribute’s value; otherwise, return the empty string.
On setting, set the value of the element’s value
content attribute to the new value.
default/on
On getting, if the element has a value content
attribute, return that attribute’s value; otherwise, return the string “on“.
On setting, set the value of the element’s value
content attribute to the new value.
filename
On getting, return the string “C:\fakepath\” followed by the name of
the first file in the list of selected
files, if any, or the empty string if the list is empty.
Since path components are not
permitted in filenames in the list of selected
files, the “\fakepath\” cannot be mistaken for a path component.
The checked
IDL attribute allows scripts to manipulate the checkedness of an input element. On getting, it
must return the current checkedness of the element; and
on setting, it must set the element’s checkedness to the
new value and set the element’s dirty checkedness
flag to true.
The files IDL
attribute allows scripts to access the element’s selected files.
On getting, if the IDL attribute applies, it must
return a FileList object that represents the current selected files. The same object must be returned
until the list of selected files changes.
If the IDL attribute does not apply, then it must instead
return null. [FILEAPI]
On setting, it must run these steps:
If the IDL attribute does not apply or the given value
is null, then return.
Replace the element’s selected
files with the given value.
The valueAsDate IDL attribute represents the value of the element, interpreted as a date.
On setting, if the valueAsDate attribute does not apply, as defined for the input element’s type attribute’s current state, then throw an
“InvalidStateError“DOMException; otherwise, if the new
value is not null and not a Date object throw a TypeError exception;
otherwise, if the new value is null or a Date object representing the NaN time value,
then set the value of the element to the empty string;
otherwise, run the algorithm to convert a
Date object to a string, as defined for that state, on the new value, and set
the value of the element to the resulting string.
The valueAsNumber IDL attribute represents the value of the element, interpreted as a number.
On getting, if the valueAsNumber attribute does not apply, as defined for the input element’s type attribute’s current state, then return a Not-a-Number (NaN)
value. Otherwise, run the algorithm to convert a
string to a number defined for that state to the element’s value; if the algorithm returned a number, then return it,
otherwise, return a Not-a-Number (NaN) value.
On setting, if the new value is infinite, then throw a TypeError exception.
Otherwise, if the valueAsNumber attribute does not apply, as defined for the input element’s type attribute’s current state, then throw an
“InvalidStateError“DOMException. Otherwise, if the new
value is a Not-a-Number (NaN) value, then set the value of
the element to the empty string. Otherwise, run the algorithm to convert a number to a string, as
defined for that state, on the new value, and set the value
of the element to the resulting string.
The stepDown(n) and stepUp(n) methods,
when invoked, must run the following algorithm:
If the element has a minimum and a maximum and there is no value greater than or equal to the
element’s minimum and less than or equal to the element’s
maximum that, when subtracted from the step base, is an integral multiple of the allowed value step, then return.
If applying the algorithm to convert a
string to a number to the string given by the element’s value does not result in an error, then let value be the result of that algorithm. Otherwise, let value
be zero.
Let valueBeforeStepping be value.
If value subtracted from the step
base is not an integral multiple of the allowed value
step, then set value to the nearest value that, when subtracted from
the step base, is an integral multiple of the allowed value step, and that is less than value if
the method invoked was the stepDown() method, and more
than value otherwise.
If the method invoked was the stepDown() method,
negate delta.
Let value be the result of adding delta to value.
If the element has a minimum, and value
is less than that minimum, then set
value to the smallest value that, when subtracted from the step base, is an integral multiple of the allowed value step, and that is more than or equal to
that minimum.
If the element has a maximum, and value
is greater than that maximum, then
set value to the largest value that, when subtracted from the step base, is an integral multiple of the allowed value step, and that is less than or equal to
that maximum.
If either the method invoked was the stepDown()
method and value is greater than valueBeforeStepping, or the method
invoked was the stepUp() method and value is
less than valueBeforeStepping, then return.
This ensures that invoking the stepUp() method on the
input element in the following example does not change the value of that element:
File and Color inputs are exempted from this check for historical
reason: their input activation behavior also shows their pickers, and has never
been guarded by an origin check.
Display a prompt to the user requesting that the user specify some files. If the multiple attribute is not set on element, 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.
As with all user interface specifications, user agents have a good deal of
freedom in how they interpret these requirements. The above text implies that a user either
dismisses the prompt or changes their selection; exactly one of these will be true. But the
mapping of these possibilities to specific user interface elements is not mandated by the
standard. For example, a user agent might interpret clicking the “Cancel” button when files were
previously selected as a change of selection to select zero files, thus firing input and change. Or it might
interpret such a click as a dismissal that leaves the selection unchanged, thus firing cancel. Similarly, it’s up to the user agent whether re-selecting
the same files as were previously selected counts as a dismissal, or as a change of
selection.
Otherwise, the user agent should show the relevant user interface for selecting a value for
element, in the way it normally would when the user interacts with the control.
When showing such a user interface, it must respect the requirements stated in the relevant
parts of the specification for how element behaves given its type attribute state. (For example, various sections describe
restrictions on the resulting value string.)
This step can have side effects, such as closing other pickers that were previously shown by
this algorithm. (If this closes a file selection picker, then per the above that will lead to
firing either input and change events, or a cancel
event.)
4.10.5.5 Common event behaviors
When the input and change events apply
(which is the case for all input controls other than buttons and those with the type attribute in the Hidden state), the events are fired to indicate that the
user has interacted with the control. The input event fires
whenever the user has modified the data of the control. The change event fires when the value is committed, if that makes sense
for the control, or else when the control loses focus.
In all cases, the input event comes before the corresponding
change event (if any).
When an input element has a defined input activation behavior, the
rules for dispatching these events, if they apply, are
given in the section above that defines the type attribute’s
state. (This is the case for all input controls with the type attribute in the Checkbox state, the Radio Button state, or the File Upload state.)
An example of a user interface involving both interactive manipulation and a
commit action would be a Range controls that use a
slider, when manipulated using a pointing device. While the user is dragging the control’s knob,
input events would fire whenever the position changed,
whereas the change event would only fire when the user
let go of the knob, committing to a specific value.
An example of a user interface with a commit action would be a Color control that consists of a single button that brings
up a color wheel: if the value only changes when the dialog
is closed, then that would be the explicit commit action. On the other hand, if manipulating the
control changes the color interactively, then there might be no commit action.
Another example of a user interface with a commit action would be a Date control that allows both text-based user input and user
selection from a drop-down calendar: while text input might not have an explicit commit step,
selecting a date from the drop down calendar and then dismissing the drop down would be a commit
action.
Examples of a user changing the element’s value would include the user typing into a text control, pasting
a new value into the control, or undoing an edit in that control. Some user interactions do not
cause changes to the value, e.g., hitting the “delete” key in an empty text control, or replacing
some text in the control with text from the clipboard that happens to be exactly the same
text.
A Range control in the form of a
slider that the user has focused and is interacting with using a keyboard would be
another example of the user changing the element’s value
without a commit step.
In the case of tasks that just fire an input event, user agents may wait for a suitable break in the user’s
interaction before queuing the tasks; for example, a
user agent could wait for the user to have not hit a key for 100ms, so as to only fire the event
when the user pauses, instead of continuously for each keystroke.
These events are not fired in response to changes made to the values of form
controls by scripts. (This is to make it easier to update the values of form controls in response
to the user manipulating the controls, without having to then filter out the script’s own changes
to avoid an infinite loop.)
