4.10 Forms

4.10.1 Introduction

This section is non-normative.

A form is a component of a Web page that has form controls, such as text fields, buttons,
checkboxes, range controls, or color pickers. A user can interact with such a form, providing data
that can then be sent to the server for further processing (e.g. returning the results of a search
or calculation). No client-side scripting is needed in many cases, though an API is available so
that scripts can augment the user experience or use forms for purposes other than submitting data
to a server.

Writing a form consists of several steps, which can be performed in any order: writing the user
interface, implementing the server-side processing, and configuring the user interface to
communicate with the server.

4.10.1.1 Writing a form's user interface

This section is non-normative.

For the purposes of this brief introduction, we will create a pizza ordering form.

Any form starts with a form element, inside which are placed the controls. Most
controls are represented by the input element, which by default provides a one-line
text field. To label a control, the label element is used; the label text and the
control itself go inside the label element. Each part of a form is considered a
paragraph, and is typically separated from other parts using p elements.
Putting this together, here is how one might ask for the customer's name:

<form>
<p><label>Customer name: <input></label></p>
</form>

To let the user select the size of the pizza, we can use a set of radio buttons. Radio buttons
also use the input element, this time with a type attribute with the value radio. To make the radio buttons work as a group, they are
given a common name using the name attribute. To group a batch
of controls together, such as, in this case, the radio buttons, one can use the
fieldset element. The title of such a group of controls is given by the first element
in the fieldset, which has to be a legend element.

The pizzeria for which this form is being written is always making mistakes, so it needs a way
to contact the customer. For this purpose, we can use form controls specifically for telephone
numbers (input elements with their type
attribute set to tel) and e-mail addresses
(input elements with their type attribute set to
email):

We can use an input element with its type
attribute set to time to ask for a delivery time. Many
of these form controls have attributes to control exactly what values can be specified; in this
case, three attributes of particular interest are min, max, and step. These set the
minimum time, the maximum time, and the interval between allowed values (in seconds). This
pizzeria only delivers between 11am and 9pm, and doesn't promise anything better than 15 minute
increments, which we can mark up as follows:

4.10.1.2 Implementing the server-side processing for a form

This section is non-normative.

The exact details for writing a server-side processor are out of scope for this specification.
For the purposes of this introduction, we will assume that the script at https://pizza.example.com/order.cgi is configured to accept submissions using the
application/x-www-form-urlencoded format,
expecting the following parameters sent in an HTTP POST body:

custname

Customer's name

custtel

Customer's telephone number

custemail

Customer's e-mail address

size

The pizza size, either small, medium, or large

topping

A topping, specified once for each selected topping, with the allowed values being bacon, cheese, onion, and mushroom

delivery

The requested delivery time

comments

The delivery instructions

4.10.1.3 Configuring a form to communicate with a server

This section is non-normative.

Form submissions are exposed to servers in a variety of ways, most commonly as HTTP GET or POST
requests. To specify the exact method used, the method
attribute is specified on the form element. This doesn't specify how the form data is
encoded, though; to specify that, you use the enctype
attribute. You also have to specify the URL of the service that will handle the
submitted data, using the action attribute.

For each form control you want submitted, you then have to give a name that will be used to
refer to the data in the submission. We already specified the name for the group of radio buttons;
the same attribute (name) also specifies the submission name.
Radio buttons can be distinguished from each other in the submission by giving them different
values, using the value attribute.

Multiple controls can have the same name; for example, here we give all the checkboxes the same
name, and the server distinguishes which checkbox was checked by seeing which values are submitted
with that name — like the radio buttons, they are also given unique values with the value attribute.

There is no particular significance to the way some of the attributes have their
values quoted and others don't. The HTML syntax allows a variety of equally valid ways to specify
attributes, as discussed in the syntax section.

For example, if the customer entered "Denise Lawrence" as their name, "555-321-8642" as their
telephone number, did not specify an e-mail address, asked for a medium-sized pizza, selected the
Extra Cheese and Mushroom toppings, entered a delivery time of 7pm, and left the delivery
instructions text field blank, the user agent would submit the following to the online Web
service:

4.10.1.4 Client-side form validation

This section is non-normative.

Forms can be annotated in such a way that the user agent will check the user's input before the
form is submitted. The server still has to verify the input is valid (since hostile users can
easily bypass the form validation), but it allows the user to avoid the wait incurred by having
the server be the sole checker of the user's input.

The simplest annotation is the required attribute,
which can be specified on input elements to indicate that the form is not to be
submitted until a value is given. By adding this attribute to the customer name, pizza size, and
delivery time fields, we allow the user agent to notify the user when the user submits the form
without filling in those fields:

It is also possible to limit the length of the input, using the maxlength attribute. By adding this to the textarea
element, we can limit users to 1000 characters, preventing them from writing huge essays to the
busy delivery drivers instead of staying focused and to the point:

When a form is submitted, invalid events are
fired at each form control that is invalid, and then at the form element itself. This
can be useful for displaying a summary of the problems with the form, since typically the browser
itself will only report one problem at a time.

4.10.1.5 Enabling client-side automatic filling of form controls

This section is non-normative.

Some browsers attempt to aid the user by automatically filling form controls rather than having
the user reenter their information each time. For example, a field asking for the user's telephone
number can be automatically filled with the user's phone number.

To help the user agent with this, the autocomplete
attribute can be used to describe the field's purpose. In the case of this form, we have three
fields that can be usefully annotated in this way: the information about who the pizza is to be
delivered to. Adding this information looks like this:

4.10.1.6 Improving the user experience on mobile devices

This section is non-normative.

Some devices, in particular those with on-screen keyboards and those in locales with languages
with many characters (e.g. Japanese), can provide the user with multiple input modalities. For
example, when typing in a credit card number the user may wish to only see keys for digits 0-9,
while when typing in their name they may wish to see a form field that by default capitalises each
word.

Using the inputmode attribute we can select appropriate
input modalities:

4.10.1.7 The difference between the field type, the autofill field name, and the input modality

This section is non-normative.

The type, autocomplete, and inputmode attributes can seem confusingly similar. For instance,
in all three cases, the string "email" is a valid value. This section
attempts to illustrate the difference between the three attributes and provides advice suggesting
how to use them.

The type attribute on input elements decides
what kind of control the user agent will use to expose the field. Choosing between different
values of this attribute is the same choice as choosing whether to use an input
element, a textarea element, a select element, a keygen
element, etc.

The autocomplete attribute, in contrast, describes
what the value that the user will enter actually represents. Choosing between different values of
this attribute is the same choice as choosing what the label for the element will be.

First, consider telephone numbers. If a page is asking for a telephone number from the user,
the right form control to use is <input type=tel>.
However, which autocomplete value to use depends on
which phone number the page is asking for, whether they expect a telephone number in the
international format or just the local format, and so forth.

For example, a page that forms part of a checkout process on an e-commerce site for a customer
buying a gift to be shipped to a friend might need both the buyer's telephone number (in case of
payment issues) and the friend's telephone number (in case of delivery issues). If the site
expects international phone numbers (with the country code prefix), this could thus look like
this:

Now, consider a person's preferred languages. The right autocomplete value is language. However, there could be a number of
different form controls used for the purpose: a free text field (<input type=text>), a drop-down list (<select>), radio buttons (<input
type=radio>), etc. It only depends on what kind of interface is desired.

The inputmode decides what kind of input modality (e.g.
keyboard) to use, when the control is a free-form text field.

Consider names. If a page just wants one name from the user, then the relevant control is <input type=text>. If the page is asking for the user's
full name, then the relevant autocomplete value is name. But if the user is Japanese, and the page is asking
for the user's Japanese name and the user's romanised name, then it would be helpful to the user
if the first field defaulted to a Japanese input modality, while the second defaulted to a Latin
input modality (ideally with automatic capitalization of each word). This is where the inputmode attribute can help:

In this example, the "section-*" keywords in
the autocomplete attributes' values tell the user agent
that the two fields expect different names. Without them, the user agent could
automatically fill the second field with the value given in the first field when the user gave a
value to the first field.

The "-jp" and "-en" parts of the
keywords are opaque to the user agent; the user agent cannot guess, from those, that the two names
are expected to be in Japanese and English respectively.

4.10.1.8 Date, time, and number formats

This section is non-normative.

In this pizza delivery example, the times are specified in the format "HH:MM": two digits for
the hour, in 24-hour format, and two digits for the time. (Seconds could also be specified, though
they are not necessary in this example.)

In some locales, however, times are often expressed differently when presented to users. For
example, in the United States, it is still common to use the 12-hour clock with an am/pm
indicator, as in "2pm". In France, it is common to separate the hours from the minutes using an
"h" character, as in "14h00".

Similar issues exist with dates, with the added complication that even the order of the
components is not always consistent — for example, in Cyprus the first of February 2003
would typically be written "1/2/03", while that same date in Japan would typically be written as
"2003年02月01日" — and even with numbers, where locales differ, for
example, in what punctuation is used as the decimal separator and the thousands separator.

It is therefore important to distinguish the time, date, and number formats used in HTML and in
form submissions, which are always the formats defined in this specification (and based on the
well-established ISO 8601 standard for computer-readable date and time formats), from the time,
date, and number formats presented to the user by the browser and accepted as input from the user
by the browser.

The format used "on the wire", i.e. in HTML markup and in form submissions, is intended to be
computer-readable and consistent irrespective of the user's locale. Dates, for instance, are
always written in the format "YYYY-MM-DD", as in "2003-02-01". Users are not expected to ever see
this format.

The time, date, or number given by the page in the wire format is then translated to the user's
preferred presentation (based on user preferences or on the locale of the page itself), before
being displayed to the user. Similarly, after the user inputs a time, date, or number using their
preferred format, the user agent converts it back to the wire format before putting it in the DOM
or submitting it.

This allows scripts in pages and on servers to process times, dates, and numbers in a
consistent manner without needing to support dozens of different formats, while still supporting
the users' needs.

The name attribute represents the
form's name within the forms collection. The
value must not be the empty string, and the value must be unique amongst the form
elements in the forms collection that it is in, if
any.

The autocomplete attribute is an
enumerated attribute. The attribute has two states. The on keyword maps to the on state, and the off keyword maps to the off state. The attribute may also be omitted. The
missing value default is the on state.
The off state indicates that by default,
form controls in the form will have their autofill field name set to "off"; the on state indicates that by default, form controls
in the form will have their autofill field name set to "on".

Returns the number of form controls in the form (excluding image buttons for historical
reasons).

form[index]

Returns the indexth element in the form (excluding image buttons for
historical reasons).

form[name]

Returns the form control (or, if there are several, a RadioNodeList of the form
controls) in the form with the given ID or name (excluding image buttons for historical reasons); or, if there
are none, returns the img element with the given ID.

Once an element has been referenced using a particular name, that name will continue being
available as a way to reference that element in this method, even if the element's actual ID or name changes, for as long as
the element remains in the Document.

If there are multiple matching items, then a RadioNodeList object containing all
those elements is returned.

Triggers a user-agent-specific asynchronous user interface to help the user fill in any
fields that have an autofill field name other than "on" or "off".

The form element will subsequently receive an event, either autocomplete, indicating that the fields have been prefilled,
or autocompleteerror (using the
AutocompleteErrorEvent interface), indicating that there was some problem (the
general class of problem is described by the reason IDL attribute on the event).

When a form element is indexed for indexed property
retrieval, the user agent must return the value returned by the item method on the elements collection, when invoked with the given index as its
argument.

Each form element has a mapping of names to elements called the past names
map. It is used to persist names of controls even when they change names.

The supported property names consist of the names obtained from the following
algorithm, in the order obtained from this algorithm:

Let sourced names be an initially empty ordered list of tuples
consisting of a string, an element, a source, where the source is either id, name,
or past, and, if the source is past, an age.

If candidate has an id attribute, add
an entry to sourced names with that id
attribute's value as the string, candidate as the element, and id as
the source.

If candidate has a name attribute,
add an entry to sourced names with that name attribute's value as the string, candidate
as the element, and name as the source.

For each img element candidate whose form owner
is the form element, run these substeps:

If candidate has an id attribute, add
an entry to sourced names with that id
attribute's value as the string, candidate as the element, and id as
the source.

If candidate has a name attribute,
add an entry to sourced names with that name attribute's value as the string, candidate
as the element, and name as the source.

For each entry past entry in the past names map add an entry
to sourced names with the past entry's name as the
string, past entry's element as the element, past as the source, and
the length of time past entry has been in the past names map as
the age.

Sort sourced names by tree order of the element entry of
each tuple, sorting entries with the same element by putting entries whose source is id
first, then entries whose source is name, and finally entries whose source is past,
and sorting entries with the same element and source by their age, oldest first.

Remove any entries in sourced names that have the empty string as
their name.

Remove any entries in sourced names that have the same name as an
earlier entry in the map.

Return the list of names from sourced names, maintaining their
relative order.

If candidates is empty, let candidates be a
liveRadioNodeList object containing all the img elements
that are descendants of the form element and that have either an id attribute or a name attribute equal
to name, in tree order.

If candidates is empty, name is the name of one of
the entries in the form element's past names map: return the object
associated with name in that map.

If candidates contains more than one node, return candidates and abort these steps.

Otherwise, candidates contains exactly one node. Add a mapping from
name to the node in candidates in the form
element's past names map, replacing the previous entry with the same name, if
any.

If the checkValidity() method is
invoked, the user agent must statically validate the constraints of the
form element, and return true if the constraint validation return a positive
result, and false if it returned a negative result.

If the reportValidity() method is
invoked, the user agent must interactively validate the constraints of the
form element, and return true if the constraint validation return a positive
result, and false if it returned a negative result.

The label element represents a caption in a user interface. The
caption can be associated with a specific form control, known as the
label element's labeled control, either using the for attribute, or by putting the form control inside the
label element itself.

The for attribute may be specified to indicate a
form control with which the caption is to be associated. If the attribute is specified, the
attribute's value must be the ID of a labelable element in the same Document as the
label element. If the attribute is specified and there is an
element in the Document whose ID is equal to the
value of the for attribute, and the first such element is a
labelable element, then that element is the label
element's labeled control.

For example, on platforms where clicking or pressing a checkbox label checks the checkbox, clicking or pressing the
label in the following snippet could trigger the user agent to run synthetic
click activation steps on the input element, as if the element itself had
been triggered by the user:

<label><input type=checkbox name=lost> Lost</label>

On other platforms, the behavior might be just to focus the control, or do nothing.

Note: The ability to click or press a label to trigger an event on a control provides
usability and accessibility benefits by increasing the hit area of a control, making it easier for a user to operate.
These benefits may be lost or reduced, if the label element contains an element with its own activation
behavior, such as a link:

The usability and accessibility benefits can be maintained by placing such elements outside the label element:

<!-- good example - link outside label means checkbox activation area includes the checkbox and all the label text -->
<label><input type=checkbox name=tac>I agree to the terms and conditions</label>
(read <a href="tandc.html">Terms and Conditions</a>)

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.

Each input element has a boolean dirty
value flag. The dirty value 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 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.

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

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 autofocus attribute controls focus.
The inputmode attribute controls the user interface's input modality for the control.
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.

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 difference between the Text state
and the Search state is primarily stylistic: on
platforms where search fields are distinguished from regular text fields, the Search state might result in an appearance consistent with
the platform's search fields rather than appearing like a regular text field.

If the element is mutable, its value should be editable by the user. User agents must not allow
users to insert "LF" (U+000A) or "CR" (U+000D) 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.

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 "LF" (U+000A) or "CR" (U+000D) characters into the element's value.

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

Unlike the URL and E-mail 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 "LF" (U+000A) or "CR" (U+000D) characters into the value.

...and the user had typed "www.w3", and the user agent had also found that the user
had visited http://www.w3.org/Consortium/#membership and
http://www.w3.org/TR/XForms/ 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 UA-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.

If the element is mutable, the user agent should allow the
user to change the e-mail address represented by its value. User agents may allow the user to set the value to a string that is not a valid e-mail
address. The user agent should act in a manner consistent with expecting the user to
provide a single e-mail address. User agents should allow the user to set the value to the empty string. User agents must not allow users to
insert "LF" (U+000A) or "CR" (U+000D) characters into the value. User agents may transform the value for display and editing; in particular, user agents should
convert punycode in 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 input element represents a control for adding, removing, and
editing the e-mail 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 e-mail 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 e-mail address, but must not allow users to set any
individual value to a string containing "," (U+002C), "LF" (U+000A), or "CR" (U+000D) 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 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) 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:

A valid e-mail 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 e-mail 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.

The input element represents a control for setting the element's
value to a string representing a specific global date and time. User agents may display
the date and time in whatever time zone is appropriate for the user.

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 Date and Time 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 and Time 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.

The following fragment shows part of a calendar application. A user can specify a date and
time for a meeting (in his local time zone, probably, though the user agent can allow the user to
change that), and since the submitted data includes the time-zone offset, the application can
ensure that the meeting is shown at the correct time regardless of the time zones used by all the
participants.

Had the application used the date and/or
time types instead, the calendar application would
have also had to explicitly determine which time zone the user intended.

For events where the precise time is to vary as the user travels (e.g. "celebrate the new
year!"), and for recurring events that are to stay at the same time for a specific geographic
location even though that location may go in and out of daylight savings time (e.g. "bring the
kid to school"), the date and/or
time types combined with a select element
(or other similar control) to pick the specific geographic location to which to anchor the time
would be more appropriate.

date values represent a "floating" time and do
not include time zone information. Care is needed when
converting values of this type to or from date data types in JavaScript and other programming
languages. In many cases, an implicit time-of-day and time zone are used to create a global
("incremental") time (an integer value that represents the offset from some arbitrary epoch time).
Processing or conversion of these values, particularly across time zones, can change the value of
the date itself. [TIMEZONES]

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

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.

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

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.

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.

<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 a pattern
attribute).

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.

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:

The input element represents a control for setting the element's
values to two strings representing numbers, but
with the caveat that the exact values are not important, enabling UAs provide a graphical
interface rather than requiring the user to type the numbers directly.

Othwerwise, let the element's values be the two
values, with the smaller value first.

Let the element's value be the result of
concatenating the element's values, separating them by
a single "," (U+002C) character, with the lower value coming first.

Whenever the user changes the element's values, the
user agent must set the element's value to the result of
concatenating the element's values, separating them by a
single "," (U+002C) character, with the lower value coming first.

When the element is suffering from a step mismatch, the user agent must round
the values represented by the element's values to, in
each case, 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.

Whenever the user agent changes the element's values
according to the three previous paragraphs, the user agent must set the element's value to the result of concatenating the element's values, separating them by a single U+002C COMMA character
(,), with the lower value coming first.

Consider a user interface that filters possible flights by departure and arrival time:

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

If none of the radio buttons in a radio button group are checked when
they are inserted into the document, 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)

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

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.

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 queue a task to first
update the element's selected files so that
it represents the user's new selection, then fire a simple event that bubbles named
input at the input element, and finally
fire a simple event that bubbles named change at the input element.

If the element is not mutable, it has no activation
behavior and the user agent must not allow the user to change the element's selection.

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

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.

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.

When any of the following events occur, unless the user agent cannot support images, or its
support for images has been disabled, or the user agent only fetches elements on demand, or the
src attribute's value is the empty string, the user agent must
resolve the value of the src attribute, relative to the element, and if that is successful,
must fetch the resulting absolute URL:

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.

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.

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

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

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.

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

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 difference between disabled and readonly is that read-only controls are still focusable, so the
user can still select the text and interact with it, whereas disabled controls are entirely
non-interactive. (For this reason, only text controls can be made read-only: it wouldn't make
sense for checkboxes or buttons, for instances.)

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

The following form has two required fields, one for an e-mail 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.

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:

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.

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 e-mail client's "Cc" field could accept multiple e-mail
addresses.

<label>Cc: <input type=email multiple name=cc></label>

If the user had, amongst many friends in his user contacts database, two friends "Arthur Dent"
(with address "art@example.net") and "Adam Josh" (with address "adamjosh@example.net"), then,
after the user has typed "a", the user agent might suggest these two e-mail 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 field, and then started typing a
second e-mail address starting with "a". 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 e-mail 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
production. [ECMA262]

If an input element has a pattern
attribute specified, and the attribute's value, when compiled as a JavaScript regular expression
with the global, ignoreCase, and multiline flags disabled (see ECMA262 Edition 5, sections 15.10.7.2
through 15.10.7.4), compiles successfully, then the resulting regular expression is the element's
compiled pattern regular expression. If the element has no such attribute, or if the
value doesn't compile successfully, then the element has no compiled pattern regular
expression. [ECMA262]

This implies that the regular expression language used for this attribute is the
same as that used in JavaScript, except that the pattern
attribute is matched against the entire value, not just any subset (somewhat as if it implied a
^(?: at the start of the pattern and a )$ at the
end).

When an input element has a pattern
attribute specified, authors should provide a description of the pattern in text near the
control. Authors may also 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.

Relying on the title
attribute alone is currently discouraged as many user agents do not expose the attribute in an
accessible manner as required by this specification (e.g. requiring a pointing device such as a
mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users,
such as anyone with a modern phone or tablet).

For example, the following snippet includes the pattern description in text below the input,
the pattern description is also included in the title attribute:

<label> Part number:
<input pattern="[0-9][A-Z]{3}" name="part"
data-x="A part number is a digit followed by three uppercase letters."/>
</label>
<p>A part number is a digit followed by three uppercase letters.</p>

The presence of the pattern description in text makes the advice available to any user regardless of device.

The presence of the pattern description in the title attribute, results in the description being announced by
assistive technology such as screen readers when the input receives focus.

If the user has attempted to submit the form with incorrect information, the presence of the title attribute text
could also 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.

In this example, the pattern description is in text below the input,
but not in the title attribute. The
aria-describedby attribute
is used to explicitly associate the text description with the control, the description is announced by
assistive technology such as screen readers when the input receives focus:

<label> Part number:
<input pattern="[0-9][A-Z]{3}" name="part" aria-describedby="description">
</label>
<p id="description">A part number is a digit followed by three uppercase letters.</p>

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

The suggestions source element is the first element in
the document 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. The user agent may use the suggestion's label to identify the suggestion if appropriate.

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

If the element's type attribute is in the Range state and the element has a multiple attribute specified

When the user selects a suggestion, the user agent must identify which value in the element's
values the user intended to update, and must then update
the element's values so that the relevant value is
changed to the value given by the selected suggestion's value, as if the user had himself set it to that value.

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 himself 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 a user-agent-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.

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.

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 "LF" (U+000A) or
"CR" (U+000D) characters.

The placeholder attribute should not be used as a
replacement for a label. For a longer hint or other advisory text, place the text
next to the control.

Use of the placeholder
attribute as a replacement for a label can reduce the
accessibility and usability of the control for a range of users including older
users and users with cognitive, mobility, fine motor skill or vision impairments.
While the hint given by the control's label is shown at all times, the short
hint given in the placeholder
attribute is only shown before the user enters a value. Furthermore,
placeholder text may be mistaken for
a pre-filled value, and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible label
reduces the size of the hit region available for setting focus on the control.

User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string or the control is not focused (or both),
e.g. by displaying it inside a blank unfocused control and hiding it otherwise.

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, it must return the current value of the
element. On setting, it must set the element's value to
the new value, set the element's dirty value
flag to true, invoke the value sanitization algorithm, if the element's
type attribute's current state defines one, and then, if
the element has a text entry cursor position, should move the text entry cursor position to the
end of the text field, unselecting any selected text and resetting the selection direction to
none.

default

On getting, if the element has a value attribute, it
must return that attribute's value; otherwise, it must return the empty string. On setting, it
must set the element's value attribute to the new
value.

default/on

On getting, if the element has a value attribute, it
must return that attribute's value; otherwise, it must return the string "on". On setting, it must set the element's value attribute to the new value.

filename

On getting, it must 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. On setting, if the new value is
the empty string, it must empty the list of selected files; otherwise, it must throw an
InvalidStateError exception.

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, if the valueAsDate
attribute applies, run the algorithm to convert a string to a Date
object defined for that state to the element's value; if the algorithm returned a Date object, then
return the time value of the object (the number of milliseconds from midnight UTC the
morning of 1970-01-01 to the time represented by the Date object), otherwise, 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.

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

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() and more than value
otherwise.

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

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

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 the control can be
focused and 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 field, pasting a
new value into the field, or undoing an edit in that field. Some user interactions do not cause
changes to the value, e.g. hitting the "delete" key in an empty text field, or replacing some text
in the field 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.)

The type attribute controls the behavior of
the button when it is activated. 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.

The value attribute gives the element's value
for the purposes of form submission. The element's value is
the value of the element's value attribute, if there is
one, or the empty string otherwise.

A button (and its value) is only included in the form submission if the button
itself was used to initiate the form submission.

If the element's type attribute is in the Menu state, the menu attribute must be specified to give the element's
menu. The value must be the ID of a menu element in
the same home subtree whose type attribute is in
the popup menu state. The attribute must not be specified if
the element's type attribute is not in the Menu state.

The size attribute gives the number of options
to show to the user. The size attribute, if specified, must
have a value that is a valid non-negative integer greater than zero.

The display size of a select element is the
result of applying the rules for parsing non-negative integers to the value of
element's size attribute, if it has one and parsing it is
successful. If applying those rules to the attribute's value is not successful, or if the size attribute is absent, then the element's display size is 4 if the element's multiple content attribute is present, and 1 otherwise.

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

When the user agent is to set the value of a new
indexed property for a given property index index to a new value value, it must instead set the
value of a new indexed property with the given property index index to
the new value value on the options
collection.

Similarly, the add() method must act like its
namesake method on that same options collection.

The remove() method must act like its
namesake method on that same options collection when it
has arguments, and like its namesake method on the ChildNode interface implemented by
the HTMLSelectElement ancestor interface Element when it has no
arguments.

The multiple, required, and size IDL attributes must reflect the
respective content attributes of the same name. The size IDL
attribute has a default value of zero.

For historical reasons, the default value of the size IDL attribute does not return the actual size used, which, in
the absence of the size content attribute, is either 1 or 4
depending on the presence of the multiple
attribute.

Sometimes, a user has to select one or more items. This example shows such an interface.

<p>Select the songs from that you would like on your Act II Mix Tape:</p>
<select multiple required name="act2">
<option value="s1">It Sucks to Be Me (Reprise)
<option value="s2">There is Life Outside Your Apartment
<option value="s3">The More You Ruv Someone
<option value="s4">Schadenfreude
<option value="s5">I Wish I Could Go Back to College
<option value="s6">The Money Song
<option value="s7">School for Monsters
<option value="s8">The Money Song (Reprise)
<option value="s9">There's a Fine, Fine Line (Reprise)
<option value="s10">What Do You Do With a B.A. in English? (Reprise)
<option value="s11">For Now
</select>

The datalist element represents a set of option elements that
represent predefined options for other controls. In the rendering, the datalist
element represents nothing and it, along with its children, should
be hidden.

The datalist element can be used in two ways. In the simplest case, the
datalist element has just option element children.

In the more elaborate case, the datalist element can be given contents that are to
be displayed for down-level clients that don't support datalist. In this case, the
option elements are provided inside a select element inside the
datalist element.

Each option element that is a descendant of the datalist element,
that is not disabled, and whose value is a string that isn't the empty string, represents a
suggestion. Each suggestion has a value and a label.

The label attribute must be specified. Its
value gives the name of the group, for the purposes of the user interface. User
agents should use this attribute's value when labeling the group of option elements
in a select element.

The disabled and label attributes must reflect the
respective content attributes of the same name.

There is no way to select an optgroup element. Only
option elements can be selected. An optgroup element merely provides a
label for a group of option elements.

The following snippet shows how a set of lessons from three courses could be offered in a
select drop-down widget:

An option element's end tag may be omitted if
the option element is immediately followed by another option element, or
if it is immediately followed by an optgroup element, or if there is no more content
in the parent element.

The label attribute provides a label for
element. The label of an option element is
the value of the label content attribute, if there is one,
or, if there is not, the value of the element's text IDL
attribute.

The value attribute provides a value for
element. The value of an option element is
the value of the value content attribute, if there is one,
or, if there is not, the value of the element's text IDL
attribute.

The Option() constructor, when called with three
or fewer arguments, overrides the initial state of the selectedness state to always be false even if the third
argument is true (implying that a selected attribute is
to be set). The fourth argument can be used to explicitly set the initial selectedness state when using the constructor.

A select element whose multiple
attribute is not specified must not have more than one descendant option element with
its selected attribute set.

The selected argument sets whether or not the element is selected. If it
is omitted, even if the defaultSelected argument is true, the element is not
selected.

The disabled IDL attribute must
reflect the content attribute of the same name. The defaultSelected IDL attribute must
reflect the selected content attribute.

The label IDL attribute, on getting, must
return the element's label. On setting, the element's
label content attribute must be set to the new value.

The value IDL attribute, on getting, must
return the element's value. On setting, the element's
value content attribute must be set to the new value.

The selected IDL attribute, on getting,
must return true if the element's selectedness
is true, and false otherwise. On setting, it must set the element's selectedness to the new value, set its dirtiness to true, and then cause the element to
ask for a reset.

On setting, the text attribute must act as if the
textContent IDL attribute on the element had been set to the new value.

The form IDL attribute's behavior depends on
whether the option element is in a select element or not. If the
option has a select element as its parent, or has an
optgroup element as its parent and that optgroup element has a
select element as its parent, then the form IDL
attribute must return the same value as the form IDL attribute
on that select element. Otherwise, it must return null.

A constructor is provided for creating HTMLOptionElement objects (in addition to
the factory methods from DOM such as createElement()): Option(text, value, defaultSelected, selected). When invoked as a
constructor, it must return a new HTMLOptionElement object (a new option
element). If the first argument is not the empty string, the new object must have as its only
child a Text node whose data is the value of that argument. Otherwise, it must have
no children. If the value argument is present, the new object must have a
value attribute set with the value of the argument as its
value. If the defaultSelected argument is true, the new object must have a
selected attribute set with no value. If the selected argument is true, the new object must have its selectedness set to true; otherwise the selectedness must be set to false, even if the defaultSelected argument is true. The element's document must be the active
document of the browsing context of the Window object on which
the interface object of the invoked constructor is found.

When a textarea is mutable, its raw value should be editable by the user: the user agent
should allow the user to edit, insert, and remove text, and to insert and remove line breaks in
the form of "LF" (U+000A) characters. Any time the user causes the element's raw value to change, the user agent must queue a
task to fire a simple event that bubbles named input at the textarea element. User agents may wait for a
suitable break in the user's interaction before queuing the task; 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.

A textarea element has a dirty value
flag, which must be initially set to false, and must be set to true whenever the user
interacts with the control in a way that changes the raw
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.

The cols attribute specifies the expected
maximum number of characters per line. If the cols
attribute is specified, its value must be a valid non-negative integer greater than
zero. If applying the rules for parsing non-negative integers to
the attribute's value results in a number greater than zero, then the element's character width is that value; otherwise, it is
20.

The user agent may use the textarea element's character width as a hint to the user as to how many
characters the server prefers per line (e.g. for visual user agents by making the width of the
control be that many characters). In visual renderings, the user agent should wrap the user's
input in the rendering so that each line is no wider than this number of characters.

The rows attribute specifies the number of
lines to show. If the rows attribute is specified, its
value must be a valid non-negative integer greater than zero. If
applying the rules for parsing non-negative integers to the attribute's value results
in a number greater than zero, then the element's character
height is that value; otherwise, it is 2.

Visual user agents should set the height of the control to the number of lines given by character height.

The wrap attribute is an enumerated
attribute with two keywords and states: the soft keyword which maps to the Soft state, and the hard keyword which maps to the Hard state. The missing value default is the
Soft state.

The Soft state indicates that the text in the
textarea is not to be wrapped when it is submitted (though it can still be wrapped in
the rendering).

The Hard state indicates that the text in the
textarea is to have newlines added by the user agent so that the text is wrapped when
it is submitted.

If the element's wrap attribute is in the Hard state, the cols attribute must be specified.

For historical reasons, the element's value is normalised in three different ways for three
different purposes. The raw value is the value as
it was originally set. It is not normalized. The API
value is the value used in the value IDL
attribute. It is normalised so that line breaks use "LF" (U+000A) characters. Finally,
there is the value, as used in form submission and other
processing models in this specification. It is normalised so that line breaks use U+000D CARRIAGE
RETURN "CRLF" (U+000A) character pairs, and in addition, if necessary given the element's
wrap attribute, additional line breaks are inserted to
wrap the text at the given width.

The element's API value is defined to be the
element's raw value with the following
transformation applied:

Replace every U+000D CARRIAGE RETURN "CRLF" (U+000A) character pair from the raw value with a single "LF" (U+000A)
character.

Replace every remaining U+000D CARRIAGE RETURN character from the raw value with a single "LF" (U+000A)
character.

Replace every occurrence of a "CR" (U+000D) character not followed by a
"LF" (U+000A) character, and every occurrence of a "LF" (U+000A) character not
preceded by a "CR" (U+000D) character, by a two-character string consisting of a
U+000D CARRIAGE RETURN "CRLF" (U+000A) character pair.

If the element's wrap attribute is in the Hard state, insert U+000D CARRIAGE RETURN "CRLF" (U+000A) character pairs into the string using a UA-defined algorithm so that each line
has no more than character width characters. For
the purposes of this requirement, lines are delimited by the start of the string, the end of the
string, and U+000D CARRIAGE RETURN "CRLF" (U+000A) character pairs.

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 placeholder attribute
should not be used as a replacement for a label. For a
longer hint or other advisory text, place the text next to the control.

Use of the placeholder
attribute as a replacement for a label can reduce the
accessibility and usability of the control for a range of users including older
users and users with cognitive, mobility, fine motor skill or vision impairments.
While the hint given by the control's label is shown at all times, the short
hint given in the placeholder
attribute is only shown before the user enters a value. Furthermore,
placeholder text may be mistaken for
a pre-filled value, and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible label
reduces the size of the hit region available for setting focus on the control.

User agents should present this hint to the user when the element's value is the empty string and the control is not
focused (e.g. by displaying it inside a blank unfocused control). All U+000D CARRIAGE
RETURN U+000A LINE FEED character pairs (CRLF) in the hint, as well as all other "CR" (U+000D) and "LF" (U+000A) characters in the hint, must be treated as line breaks when
rendering the hint.

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
textarea element with its form owner.
The autofocus attribute controls focus.
The inputmode attribute controls the user interface's input
modality for the control.
The autocomplete attribute controls how the user agent
provides autofill behavior.

The defaultValue IDL attribute must
act like the element's textContent IDL attribute.

The value attribute must, on getting, return
the element's API value; on setting, it must set
the element's raw value to the new value, set the
element's dirty value flag to true, and should then
move the text entry cursor position to the end of the text field, unselecting any selected text
and resetting the selection direction to none.

The keygen element represents a key pair generator control. When the
control's form is submitted, the private key is stored in the local keystore, and the public key
is packaged and sent to the server.

The challenge attribute may be specified.
Its value will be packaged with the submitted key.

The keytype attribute 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 listed in the cell in the
second column on the same row as the keyword. User agents are not required to support these
values, and must only recognise values whose corresponding algorithms they support.

Keyword

State

rsa

RSA

The invalid value default state is the unknown state. The missing
value default state is the RSA state, if it is supported, or the unknown state otherwise.

This specification does not specify what key types user agents are to support
— it is possible for a user agent to not support any key types at all.

The user agent may expose a user interface for each keygen element to allow the
user to configure settings of the element's key pair generator, e.g. the key length.

The reset algorithm for keygen
elements is to set these various configuration settings back to their defaults.

The element's value is the string returned from the
following algorithm:

Generate an RSA key pair using the settings given by the user, if appropriate, using the
md5WithRSAEncryption RSA signature algorithm (the signature algorithm
with MD5 and the RSA encryption algorithm) referenced in section 2.2.1 ("RSA Signature
Algorithm") of RFC 3279, and defined in RFC 2313. [RFC3279][RFC2313]

The given key type is not supported. Return the empty string and abort this algorithm.

Let private key be the generated private key.

Let public key be the generated public key.

Let signature algorithm be the selected signature algorithm.

If the element has a challenge attribute, then let
challenge be that attribute's value. Otherwise, let challenge be the empty string.

Let algorithm be an ASN.1 AlgorithmIdentifier
structure as defined by RFC 5280, with the algorithm field giving the
ASN.1 OID used to identify signature algorithm, using the OIDs defined in
section 2.2 ("Signature Algorithms") of RFC 3279, and the parameters field
set up as required by RFC 3279 for AlgorithmIdentifier structures for that
algorithm. [X690][RFC5280][RFC3279]

Let spki be an ASN.1 SubjectPublicKeyInfo structure
as defined by RFC 5280, with the algorithm field set to the algorithm structure from the previous step, and the subjectPublicKey field set to the BIT STRING value resulting from ASN.1 DER
encoding the public key. [X690][RFC5280]

Let publicKeyAndChallenge be an ASN.1 PublicKeyAndChallenge
structure as defined below, with the spki field set to the spki structure from the previous step, and the challenge
field set to the string challenge obtained earlier. [X690]

Let signature be the BIT STRING value resulting from ASN.1 DER encoding
the signature generated by applying the signature algorithm to the byte
string obtained by ASN.1 DER encoding the publicKeyAndChallenge structure,
using private key as the signing key. [X690]

Let signedPublicKeyAndChallenge be an ASN.1
SignedPublicKeyAndChallenge structure as defined below, with the publicKeyAndChallenge field set to the publicKeyAndChallenge
structure, the signatureAlgorithm field set to the algorithm structure, and the signature field set to the BIT
STRING signature from the previous step. [X690]

Return the result of base64 encoding the result of ASN.1 DER encoding the signedPublicKeyAndChallenge structure. [RFC4648][X690]

The data objects used by the above algorithm are defined as follows. These definitions use the
same "ASN.1-like" syntax defined by RFC 5280. [RFC5280]

The form attribute is used to explicitly associate the
keygen element with its form owner. The name attribute represents the element's name. The disabled attribute is used to make the control non-interactive and
to prevent its value from being submitted. The autofocus
attribute controls focus.

keygen . type

Returns the string "keygen".

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

This specification does not specify how the private key generated is to be used.
It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC)
structure, the server will generate a client certificate and offer it back to the user for
download; this certificate, once downloaded and stored in the key store along with the private
key, can then be used to authenticate to services that use TLS and certificate authentication. For
more information, see e.g. this MDN article.

To generate a key pair, add the private key to the user's key store, and submit the public key
to the server, markup such as the following can be used:

The server will then receive a form submission with a packaged RSA public key as the value of
"key". This can then be used for various purposes, such as generating a
client certificate, as mentioned above.

The output element represents the result of a calculation performed
by the application, or the result of a user action.

This element can be contrasted with the samp element, which is the
appropriate element for quoting the output of other programs run previously.

The for content attribute allows an explicit
relationship to be made between the result of a calculation and the elements that represent the
values that went into the calculation or that otherwise influenced the calculation. The for attribute, if specified, must contain a string consisting of an
unordered set of unique space-separated tokens that are case-sensitive,
each of which must have the value of an ID of an element in the
same Document.

The form attribute is used to explicitly associate the
output element with its form owner. The name attribute represents the element's name.

The element has a value mode flag which is either value or default.
Initially, the value mode flag must be set to default.

The element also has a default value. Initially,
the default value must be the empty string.

The value IDL attribute must act like the
element's textContent IDL attribute, except that on setting, in addition, before the
child nodes are changed, the element's value mode flag
must be set to value.

The defaultValue IDL attribute, on
getting, must return the element's default value.
On setting, the attribute must set the element's default
value, and, if the element's value mode flag is in
the mode default, set the element's
textContent IDL attribute as well.

The progress element represents the completion progress of a task.
The progress is either indeterminate, indicating that progress is being made but that it is not
clear how much more work remains to be done before the task is complete (e.g. because the task is
waiting for a remote host to respond), or the progress is a number in the range zero to a maximum,
giving the fraction of work that has so far been completed.

There are two attributes that determine the current task completion represented by the element.
The value attribute specifies how much of the
task has been completed, and the max attribute
specifies how much work the task requires in total. The units are arbitrary and not specified.

To make a determinate progress bar, add a value attribute with the current progress (either a number from
0.0 to 1.0, or, if the max attribute is specified, a number
from 0 to the value of the max attribute). To make an
indeterminate progress bar, remove the value
attribute.

Authors are encouraged to also include the current value and the maximum value inline as text
inside the element, so that the progress is made available to users of legacy user agents.

Here is a snippet of a Web application that shows the progress of some automated task:

(The updateProgress() method in this example would be called by some other code
on the page to update the actual progress bar as the task progressed.)

The value and max attributes, when present, must have values that are valid floating-point numbers. The value attribute, if present, must have a value equal to or
greater than zero, and less than or equal to the value of the max attribute, if present, or 1.0, otherwise. The max attribute, if present, must have a value greater than
zero.

The progress element is the wrong element to use for something that
is just a gauge, as opposed to task progress. For instance, indicating disk space usage using
progress would be inappropriate. Instead, the meter element is available
for such use cases.

User agent requirements: If the value
attribute is omitted, then the progress bar is an indeterminate progress bar. Otherwise, it is a
determinate progress bar.

If the progress bar is a determinate progress bar and the element has a max attribute, the user agent must parse the max attribute's value according to the rules for parsing
floating-point number values. If this does not result in an error, and if the parsed value
is greater than zero, then the maximum value of the
progress bar is that value. Otherwise, if the element has no max attribute, or if it has one but parsing it resulted in an
error, or if the parsed value was less than or equal to zero, then the maximum value of the progress bar is 1.0.

If the progress bar is a determinate progress bar, user agents must parse the value attribute's value according to the rules for
parsing floating-point number values. If this does not result in an error, and if the
parsed value is less than the maximum value and
greater than zero, then the current value of the
progress bar is that parsed value. Otherwise, if the parsed value was greater than or equal to the
maximum value, then the current value of the progress bar is the maximum value of the progress bar. Otherwise, if parsing
the value attribute's value resulted in an error, or a
number less than or equal to zero, then the current
value of the progress bar is zero.

UA requirements for showing the progress bar: When representing a
progress element to the user, the UA should indicate whether it is a determinate or
indeterminate progress bar, and in the former case, should indicate the relative position of the
current value relative to the maximum value.

Setting the value IDL attribute to itself
when the corresponding content attribute is absent would change the progress bar from an
indeterminate progress bar to a determinate progress bar with no progress.

The meter element represents a scalar measurement within a known
range, or a fractional value; for example disk usage, the relevance of a query result, or the
fraction of a voting population to have selected a particular candidate.

This is also known as a gauge.

The meter element should not be used to indicate progress (as in a
progress bar). For that role, HTML provides a separate progress element.

The meter element also does not represent a scalar value of arbitrary
range — for example, it would be wrong to use this to report a weight, or height, unless
there is a known maximum value.

There are six attributes that determine the semantics of the gauge represented by the
element.

The min attribute specifies the lower bound of
the range, and the max attribute specifies the
upper bound. The value attribute specifies the
value to have the gauge indicate as the "measured" value.

The other three attributes can be used to segment the gauge's range into "low", "medium", and
"high" parts, and to indicate which part of the gauge is the "optimum" part. The low attribute specifies the range that is considered to
be the "low" part, and the high attribute
specifies the range that is considered to be the "high" part. The optimum attribute gives the position that is
"optimum"; if that is higher than the "high" value then this indicates that the higher the value,
the better; if it's lower than the "low" mark then it indicates that lower values are better, and
naturally if it is in between then it indicates that neither high nor low values are good.

User agents must then use all these numbers to obtain values for six points on the gauge, as
follows. (The order in which these are evaluated is important, as some of the values refer to
earlier ones.)

The minimum value

If the min attribute is specified and a value could be
parsed out of it, then the minimum value is that value. Otherwise, the minimum value is
zero.

The maximum value

If the max attribute is specified and a value could be
parsed out of it, then the candidate maximum value is that value. Otherwise, the candidate
maximum value is 1.0.

If the candidate maximum value is greater than or equal to the minimum value, then the
maximum value is the candidate maximum value. Otherwise, the maximum value is the same as the
minimum value.

The actual value

If the value attribute is specified and a value could
be parsed out of it, then that value is the candidate actual value. Otherwise, the candidate
actual value is zero.

If the candidate actual value is less than the minimum value, then the actual value is the
minimum value.

Otherwise, if the candidate actual value is greater than the maximum value, then the actual
value is the maximum value.

Otherwise, the actual value is the candidate actual value.

The low boundary

If the low attribute is specified and a value could be
parsed out of it, then the candidate low boundary is that value. Otherwise, the candidate low
boundary is the same as the minimum value.

If the candidate low boundary is less than the minimum value, then the low boundary is the
minimum value.

Otherwise, if the candidate low boundary is greater than the maximum value, then the low
boundary is the maximum value.

Otherwise, the low boundary is the candidate low boundary.

The high boundary

If the high attribute is specified and a value could be
parsed out of it, then the candidate high boundary is that value. Otherwise, the candidate high
boundary is the same as the maximum value.

If the candidate high boundary is less than the low boundary, then the high boundary is the
low boundary.

Otherwise, if the candidate high boundary is greater than the maximum value, then the high
boundary is the maximum value.

Otherwise, the high boundary is the candidate high boundary.

The optimum point

If the optimum attribute is specified and a value
could be parsed out of it, then the candidate optimum point is that value. Otherwise, the
candidate optimum point is the midpoint between the minimum value and the maximum value.

If the candidate optimum point is less than the minimum value, then the optimum point is the
minimum value.

Otherwise, if the candidate optimum point is greater than the maximum value, then the optimum
point is the maximum value.

Otherwise, the optimum point is the candidate optimum point.

All of which will result in the following inequalities all being true:

minimum value ≤ actual value ≤ maximum value

minimum value ≤ low boundary ≤ high boundary ≤ maximum value

minimum value ≤ optimum point ≤ maximum value

UA requirements for regions of the gauge: If the optimum point is equal to the
low boundary or the high boundary, or anywhere in between them, then the region between the low
and high boundaries of the gauge must be treated as the optimum region, and the low and high
parts, if any, must be treated as suboptimal. Otherwise, if the optimum point is less than the low
boundary, then the region between the minimum value and the low boundary must be treated as the
optimum region, the region from the low boundary up to the high boundary must be treated as a
suboptimal region, and the remaining region must be treated as an even less good region. Finally,
if the optimum point is higher than the high boundary, then the situation is reversed; the region
between the high boundary and the maximum value must be treated as the optimum region, the region
from the high boundary down to the low boundary must be treated as a suboptimal region, and the
remaining region must be treated as an even less good region.

UA requirements for showing the gauge: When representing a meter
element to the user, the UA should indicate the relative position of the actual value to the
minimum and maximum values, and the relationship between the actual value and the three regions of
the gauge.

The fieldset element represents a set of form controls optionally
grouped under a common name.

The name of the group is given by the first legend element that is a child of the
fieldset element, if any. The remainder of the descendants form the group.

The disabled attribute, when specified,
causes all the form control descendants of the fieldset element, excluding those that
are descendants of the fieldset element's first legend element child, if
any, to be disabled.

The form attribute is used to explicitly associate the
fieldset element with its form owner. The name attribute represents the element's name.

The following snippet shows a fieldset with a checkbox in the legend that controls whether or
not the fieldset is enabled. The contents of the fieldset consist of two required text fields and
an optional year/month control.

In this example, if the outer "Use Club Card" checkbox is not checked, everything inside the
outer fieldset, including the two radio buttons in the legends of the two nested
fieldsets, will be disabled. However, if the checkbox is checked, then the radio
buttons will both be enabled and will let you select which of the two inner
fieldsets is to be enabled.

The form IDL attribute's behavior depends on
whether the legend element is in a fieldset element or not. If the
legend has a fieldset element as its parent, then the form IDL attribute must return the same value as the form IDL attribute on that fieldset element. Otherwise,
it must return null.

4.10.18 Form control infrastructure

4.10.18.1 A form control's value

Most form controls have a value and a checkedness. (The latter is only used by input
elements.) These are used to describe how the user interacts with the control.

To define the behaviour of constraint validation in the face of the input
element's multiple attribute, input elements
can also have separately defined values.

4.10.18.2 Mutability

A form control can be designated as mutable.

This determines (by means of definitions and requirements in this specification
that rely on whether an element is so designated) whether or not the user can modify the value or checkedness of a
form control, or whether or not a control can be automatically prefilled.

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

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

The form owner of "d" would be the inner nested form "c", while the form
owner of "e" would be the outer form "a".

This happens as follows: First, the "e" node gets associated with "c" in the HTML
parser. Then, the innerHTML algorithm moves the nodes
from the temporary document to the "b" element. At this point, the nodes see their ancestor chain
change, and thus all the "magic" associations done by the parser are reset to normal ancestor
associations.

This example is a non-conforming document, though, as it is a violation of the content models
to nest form elements.

4.10.19 Attributes common to form controls

The name content attribute gives the name of the
form control, as used in form submission and in the form element's elements object. If the attribute is specified, its value must
not be the empty string.

This value, if used as the name of a Text control
that is the first control in a form that is submitted using the application/x-www-form-urlencoded mechanism, causes
the submission to only include the value of this control, with no name.

_charset_

This value, if used as the name of a Hidden
control with no value attribute, is automatically given a
value during submission consisting of the submission character encoding.

The dirname attribute on a form control element
enables the submission of the directionality of the element, and gives the name of
the field that contains this value during form submission. If such an attribute is
specified, its value must not be the empty string.

In this example, a form contains a text field and a submission button:

When the user submits the form, the user agent includes three fields, one called "comment",
one called "comment.dir", and one called "mode"; so if the user types "Hello", the submission
body might be something like:

comment=Hello&comment.dir=ltr&mode=add

If the user manually switches to a right-to-left writing direction and enters "مرحبا", the submission body might be
something like:

A form control minlength attribute,
controlled by a dirty value flag, declares a lower bound on the number of
characters a user can input.

The minlength attribute does not imply the
required attribute. If the form control has no minlength attribute, then the value can still be omitted; the
minlength attribute only kicks in once the user has entered
a value at all. If the empty string is not allowed, then the required
attribute also needs to be set.

In this example, there are four text fields. The first is required, and has to be at least 5
characters long. The other three are optional, but if the user fills one in, the user has to
enter at least 10 characters.

<form action="/events/menu.cgi" method="post">
<p><label>Name of Event: <input required minlength=5 maxlength=50 name=event></label></p>
<p><label>Describe what you would like for breakfast, if anything:
<textarea name="breakfast" minlength="10"></textarea></label></p>
<p><label>Describe what you would like for lunch, if anything:
<textarea name="lunch" minlength="10"></textarea></label></p>
<p><label>Describe what you would like for dinner, if anything:
<textarea name="dinner" minlength="10"></textarea></label></p>
<p><input type=submit value="Submit Request"></p>
</form>

4.10.19.5 Enabling and disabling form controls: the disabled attribute

A form control is disabled if its disabled attribute is set, or if it is a descendant of a
fieldset element whose disabled attribute
is set and is not a descendant of that fieldset element's first
legend element child, if any.

4.10.19.6 Form submission

Attributes for form submission can be specified both on form elements
and on submit buttons (elements that represent buttons
that submit forms, e.g. an input element whose type attribute is in the Submit Button state).

The action of an element is the value of the element's
formaction attribute, if the element is a submit button and has such an attribute, or the value of its
form owner's action attribute, if it has
one, or else the empty string.

The method and formmethod content attributes are enumerated attributes with the following keywords and
states:

The keyword get, mapping to the
state GET, indicating the HTTP GET method.

The keyword post, mapping to the
state POST, indicating the HTTP POST method.

The keyword dialog, mapping to
the state dialog, indicating that submitting the
form is intended to close the dialog box in which the form finds
itself, if any, and otherwise not submit.

The invalid value default for these attributes is the GET state. The missing value default for the method attribute is also the GET state. (There is no missing value default for the
formmethod attribute.)

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

Here the method attribute is used to explicitly specify
the default value, "get", so that the search
query is submitted in the URL:

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

The novalidate and formnovalidate content attributes are boolean attributes. If present, they indicate that the form is
not to be validated during submission.

This attribute is useful to include "save" buttons on forms that have validation constraints,
to allow users to save their progress even though they haven't fully entered the data in the
form. The following example shows a simple form that has two required fields. There are three
buttons: one to submit the form, which requires both fields to be filled in; one to save the form
so that the user can come back and fill it in later; and one to cancel the form altogether.

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

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

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

Queue a task that checks to see if the element is focusable, and
if so, runs the focusing steps for that element. User agents may also change the
scrolling position of the document, or perform some other action that brings the element to the
user's attention. The task source for this task is the user interaction task
source.

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

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

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

Latin-script input in the user's preferred language(s), with typing aids intended for
entering human names enabled (e.g. text prediction from the user's contact list and automatic
capitalisation at every word). Intended for situations such as customer name fields.

Latin-script input in the user's preferred language(s), with aggressive typing aids
intended for human-to-human communications enabled (e.g. text prediction and automatic
capitalisation at the start of sentences). Intended for situations such as e-mails and instant
messaging.

Kana or romaji input, typically hiragana input, using full-width characters, with support
for converting to kanji, and with typing aids intended for entering human names enabled (e.g.
text prediction from the user's contact list). Intended for situations such as customer name
fields.

Telephone number input, including keys for the digits 0 to 9, the "#" character, and the
"*" character. In some locales, this can also include alphabetic mnemonic labels (e.g. in the
US, the key labeled "2" is historically also labeled with the letters A, B, and C). Rarely necessary; use "<input
type=tel>" instead.

Text input in the user's locale, with keys for aiding in the input of Web addresses, such
as that for the "/" and "." characters and for quick input of strings commonly found in domain
names such as "www." or ".co.uk". Rarely necessary; use "<input type=url>" instead.

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

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

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

4.10.19.8 Autofill

User agents sometimes have features for helping users fill forms in, for example prefilling the
user's address based on earlier user input. The autocomplete content attribute can be used to hint
to the user agent how to, or indeed whether to, provide such a feature.

The "off" keyword indicates either
that the control's input data is particularly sensitive (for example the activation code for a
nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a
bank login) and the user will therefore have to explicitly enter the data each time, instead of
being able to rely on the UA to prefill the value for him; or that the document provides its own
autocomplete mechanism and does not want the user agent to provide autocompletion values.

The "on" keyword indicates that the
user agent is allowed to provide the user with autocompletion values, but does not provide any
further information about what kind of data the user might be expected to enter. User agents would
have to use heuristics to decide what autocompletion values to suggest.

The autofill fields names listed above indicate that the user
agent is allowed to provide the user with autocompletion values, and specifies what kind of value
is expected. The keywords relate to each other as described in the table below. Each field name
listed on a row of this table corresponds to the meaning given in the cell for that row in the
column labeled "Meaning". Some fields correspond to subparts of other fields; for example, a
credit card expiry date can be expressed as one field giving both the month and year of expiry
("cc-exp"), or as two fields, one giving the
month ("cc-exp-month") and one the year
("cc-exp-year"). In such cases, the names of
the broader fields cover multiple rows, in which the narrower fields are defined.

Generally, authors are encouraged to use the broader fields rather than the
narrower fields, as the narrower fields tend to expose Western biases. For example, while it is
common in some Western cultures to have a given name and a family name, in that order (and thus
often referred to as a first name and a surname), many cultures put the family name
first and the given name second, and many others simply have one name (a mononym). Having a
single field is therefore more flexible.

Some fields are only appropriate for certain form controls. An autofill field name
is inappropriate for a control if the control
does not belong to the group listed for that autofill field in the fifth column of
the first row describing that autofill field in the table below. What controls fall
into each group is described below the table.

The autofill scope identifies the group of fields that are to be filled with the
information from the same source, and consists of the autofill hint set with, if
applicable, the "section-*" prefix, e.g. "billing", "section-parent shipping", or "section-child home
shipping".

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

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

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

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

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

Decrement index by one.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2012-07

The day is dropped since the Month state only accepts a
month/year combination.

The user agent picks the month from the listed options, either by noticing there are twelve
options and picking the 7th, or by recognising that one of the strings (three characters "Jul"
followed by a newline and a space) is a close match for the name of the month (July) in one of
the user agent's supported languages, or through some other similar mechanism.

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

7

User agent converts "July" to a month number in the range 1..12, like the field.

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

6

User agent converts "July" to a month number in the range 0..11, like the field.

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

User agent doesn't fill in the field, since it can't make a good guess as to what the form expects.

A user agent may allow the user to override an element's autofill field name, e.g.
to change it from "off" to "on" to allow values to be remembered and prefilled despite
the page author's objections, or to always "off",
never remembering values. However, user agents should not allow users to trivially override the
autofill field name from "off" to
"on" or other values, as there are significant
security implications for the user if all values are always remembered, regardless of the site's
preferences.

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

4.10.19.8.3 User interface for bulk autofill

When the requestAutocomplete()
method on a form element is invoked, the user agent must run the following steps:

When the user agent is required to fail the autofill request on a form
element target with a reason reason, the user agent must
dispatch an event that uses the AutocompleteErrorEvent interface, with the event type
autocompleteerror, which bubbles, is not cancelable, has no default action,
has its reason attribute set to reason, and which is trusted, at target.

The reason attribute must
return the value it was initialised to. When the object is created, this attribute must be
initialised to the empty string. It
represents the context information for the event.

4.10.20 APIs for the text field selections

The input and textarea elements define the following members in their
DOM interfaces for handling their selection:

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

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

The selections of input and textarea elements have a
direction, which is either forward, backward, or none. This direction
is set when the user manipulates the selection. The exact meaning of the selection direction
depends on the platform.

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

The select() method must cause the
contents of the text field to be fully selected, with the selection direction being none, if the
platform support selections with the direction none, or otherwise forward. The user
agent must then queue a task to fire a simple event that bubbles named
select at the element, using the user interaction task
source as the task source.

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

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

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

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

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

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

The setSelectionRange(start, end, direction) method
must set the selection of the text field to the sequence of characters starting with the character
at the startth position (in logical order) and ending with the character at
the (end-1)th position. Arguments greater than the
length of the value of the text field must be treated as pointing at the end of the text field. If
end is less than or equal to start then the start of the
selection and the end of the selection must both be placed immediately before the character with
offset end. In UAs where there is no concept of an empty selection, this must
set the cursor to be just before the character with offset end. The direction
of the selection must be set to backward if direction is a
case-sensitive match for the string "backward", forward
if direction is a case-sensitive match for the string "forward" or if the platform does not support selections with the direction
none, and none otherwise (including if the argument is omitted). The user agent must
then queue a task to fire a simple event that bubbles named select at the element, using the user interaction task
source as the task source.

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

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

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

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

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

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

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

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

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

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

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

Run the appropriate set of substeps from the following list:

If the fourth argument's value is "select"

Let selection start be start.

Let selection end be new end.

If the fourth argument's value is "start"

Let selection start and selection end be start.

If the fourth argument's value is "end"

Let selection start and selection end be new end.

If the fourth argument's value is "preserve" (the default)

Let old length be end minus start.

Let delta be new length minus old length.

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

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

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

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

Set the selection of the text field to the sequence of characters starting with the character
at the selection startth position (in logical order) and ending with the
character at the (selection end-1)th position. In UAs
where there is no concept of an empty selection, this must set the cursor to be just before the
character with offset end. The direction of the selection must be set to
forward if the platform does not support selections with the direction none, and
none otherwise.

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

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

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

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