<section>

<!--

Forms

This source produces section 4.10: Forms

https://w3c.github.io/html/sec-forms.html

It covers:

- Introduction to forms including:

+ Form's user interface

+ Server and client side information

+ Differences between field type, autofill name, and input modality

+ Date, time, and number formats

- Categories

- Form Elements:

+ form, label, input states and types, button, select, datalist,

optgroup, option, textarea, output, meter, fieldset, legend,

and progress

- Form control infrastructure

- Attributes common to form controls

+ including name, dirname, disabled, etc.

- APIs for text field selections

- Constraints

- Form submission

- Resetting a form

-->

<h3 id="sec-forms"><dfn>Forms</dfn></h3>

<h4 id="forms-introduction">Introduction</h4>

<em>This section is non-normative.</em>

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.

<h5 id="writing-a-forms-user-interface">Writing a form's user interface</h5>

<em>This section is non-normative.</em>

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. One way to associate a label with a control is to nest

the label text, and the control itself, inside a <{label}> element. Each area within a form is

typically represented using a <{div}> element. Putting this all together, here is how one might

ask for the customer's name:

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input>

</label>

</div>

</form>

</xmp>

<p class="note">

For an alternate method to associate a <{label}> with a form control, please refer to the

<code>label</code>'s <{label/for}> attribute.

</p>

To assist users with entering their names, an <{input/autocapitalize}> attribute with the value

of "words" can be added to the <{input}> so that user agents are provided a suggestion to

automatically capitalize the first character(s) of a user's entered name.

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input autocapitalize="words">

</label>

</div>

</form>

</xmp>

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, but with a <{input/type}> attribute with the value

<code>radio</code>. To make the radio buttons work as a group, they are each given a common name

using the <{input/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.

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input autocapitalize="words">

</label>

</div>

<fieldset>

<legend>Pizza Size</legend>

<ul>

<li>

<label>

<input type="radio" name="size"> Small

</label>

</li>

<li>

<label>

<input type="radio" name="size"> Large

</label>

</li>

</ul>

</fieldset>

</form>

</xmp>

To choose toppings, checkboxes can be added to this form. Checkboxes use the <{input}> element

with a <{input/type}> attribute with the value <code>checkbox</code>:

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input autocapitalize="words">

</label>

</div>

<fieldset>

<legend>Pizza Size</legend>

<ul>

<li>

<label>

<input type="radio" name="size"> Small

</label>

</li>

<li>

<label>

<input type="radio" name="size"> Large

</label>

</li>

</ul>

</fieldset>

<fieldset>

<legend>Pizza Toppings</legend>

<ul>

<li>

<label>

<input type="checkbox"> Bacon

</label>

</li>

<li>

<label>

<input type="checkbox"> Onion

</label>

</li>

<li>

<label>

<input type="checkbox"> Mushroom

</label>

</li>

</ul>

</fieldset>

</form>

</xmp>

In the event there is a problem with a customer's order, the pizzeria needs a way to be able to

collect the customer's contact information. For this purpose, form controls for telephone numbers

(<{input}> elements with a <{input/type}> attribute set to <code>tel</code>) and

e-mail addresses (<{input}> elements with a <{input/type}> attribute set to code>email</code>)

can be added:

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input autocapitalize="words">

</label>

</div>

<div>

<label>

Telephone: <input type="tel">

</label>

</div>

<div>

<label>

E-mail: <input type="email">

</label>

</div>

...

</form>

</xmp>

To let customers request a specific delivery time an <{input}> element with its <{input/type}>

attribute set to <code>time</code> can be used. Many form controls have attributes to help

authors dictate the values a user can enter; in this case, three attributes of particular

interest are <{input/min}>, <{input/max}>, and <{input/step}>. Respectively, these set the

minimum time, the maximum time, and the interval between allowed values (in seconds).

For this example, the pizzeria only delivers between 11am and 9pm, and allows users to choose a

delivery window in 15 minute increments. As the <{input/min}>, <{input/max}> attributes take

values in 24-hour time, this means the <code>min</code> value would be "11:00" and the

<code>max</code> value would be "21:00". Since the <{input/step}> attribute is set in seconds,

to set the form control to accept values in 15 minute increments, the 15 minutes would need to

be converted to seconds (900 seconds).

<xmp highlight="html">

<form>

...

<div>

<label>

Preferred delivery time:

<input type="time" min="11:00" max="21:00" step="900">

</label>

</div>

</form>

</xmp>

The <{textarea}> element can be used to provide a free-form text field. In this instance, it will

allow a space for customers to provide delivery instructions:

<xmp highlight="html">

<form>

...

<div>

<label>

Delivery instructions:

<textarea></textarea>

</label>

</div>

</form>

</xmp>

Finally, to make the form submittable, add a <{button}> element:

<xmp highlight="html">

<form>

<div>

<label>

Customer name: <input autocapitalize="words">

</label>

</div>

<div>

<label>

Telephone: <input type="tel">

</label>

</div>

<div>

<label>

E-mail: <input type="email">

</label>

</div>

<fieldset>

<legend>Pizza Size</legend>

<ul>

<li>

<label>

<input type="radio" name="size"> Small

</label>

</li>

<li>

<label>

<input type="radio" name="size"> Large

</label>

</li>

</ul>

</fieldset>

<fieldset>

<legend>Pizza Toppings</legend>

<ul>

<li>

<label>

<input type="checkbox"> Bacon

</label>

</li>

<li>

<label>

<input type="checkbox"> Onion

</label>

</li>

<li>

<label>

<input type="checkbox"> Mushroom

</label>

</li>

</ul>

</fieldset>

<div>

<label>

Preferred delivery time:

<input type="time" min="11:00" max="21:00" step="900">

</label>

</div>

<div>

<label>

Delivery instructions:

<textarea></textarea>

</label>

</div>

<div>

<button>Submit order</button>

</div>

</form>

</xmp>

<h5 id="implementing-the-serverside-processing-for-a-form">Implementing the server-side processing for a form</h5>

<em>This section is non-normative.</em>

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

<code>https://pizza.example.com/order</code> is configured to accept submissions using the

<code>application/x-www-form-urlencoded</code> format, expecting the following parameters sent

in an HTTP POST body:

: <code>custname</code>

:: Customer's name

: <code>custtel</code>

:: Customer's telephone number

: <code>custemail</code>

:: Customer's e-mail

: <code>size</code>

:: The pizza size, either <code>small</code> or <code>large</code>

: <code>topping</code>

:: A topping, specified once for each selected topping, with the allowed values being

<code>bacon</code>, <code>onion</code>, and <code>mushroom</code>

: <code>delivery</code>

:: The requested delivery time

: <code>comments</code>

:: The delivery instructions

<h5 id="configuring-a-form-to-communicate-with-a-server">Configuring a form to communicate with a server</h5>

<em>This section is non-normative.</em>

<a>Form submissions</a> are exposed to servers in a variety of ways, most commonly as HTTP GET or

POST requests. To specify the exact method used, the <{form/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 <{form/enctype}>

attribute. You also have to specify the [=url/URL=] of the service that will handle the

submitted data, using the <{form/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 (<{formelements/name}>) also specifies the submission name.

Radio buttons can be distinguished from each other in the submission by giving them different

values, using the <code>value</code> 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

<code>value</code> attribute.

Given the settings in the previous section, this all becomes:

<xmp highlight="html">

<form method="post" enctype="application/x-www-form-urlencoded" action="https://pizza.example.com/order">

<div>

<label>

Customer name: <input name="custname">

</label>

</div>

<div>

<label>

Telephone: <input type="tel" name="custtel">

</label>

</div>

<div>

<label>

E-mail: <input type="email" name="custemail">

</label>

</div>

<fieldset>

<legend>Pizza Size</legend>

<ul>

<li>

<label>

<input type="radio" name="size"> Small

</label>

</li>

<li>

<label>

<input type="radio" name="size"> Large

</label>

</li>

</ul>

</fieldset>

<fieldset>

<legend>Pizza Toppings</legend>

<ul>

<li>

<label>

<input type="checkbox"> Bacon

</label>

</li>

<li>

<label>

<input type="checkbox"> Onion

</label>

</li>

<li>

<label>

<input type="checkbox"> Mushroom

</label>

</li>

</ul>

</fieldset>

<div>

<label>

Preferred delivery time:

<input type="time" min="11:00" max="21:00" step="900" name="delivery">

</label>

</div>

<div>

<label>

Delivery instructions:

<textarea name="comments"></textarea>

</label>

</div>

<div>

<button>Submit order</button>

</div>

</form>

</xmp>

For example, if the customer entered "Denise Lawrence" as their name, "555-555-8642" as their

telephone number, did not specify an e-mail, asked for a small pizza, selected the

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

<pre>custname=Denise+Lawrence&amp;custtel=555-555-8642&amp;custemail=&amp;size=small&amp;topping=onion&amp;topping=mushroom&amp;delivery=19%3A00&amp;comments=</pre>

<h5 id="clientside-form-validation">Client-side form validation</h5>

<em>This section is non-normative.</em>

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 <{input/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 the necessary fields:

<xmp highlight="html">

<form method="post" enctype="application/x-www-form-urlencoded" action="https://pizza.example.com/order">

<div>

<label>

Customer name: <input name="custname" required>

</label>

</div>

<div>

<label>

Telephone: <input type="tel" name="custtel">

</label>

</div>

<div>

<label>

E-mail: <input type="email" name="custemail">

</label>

</div>

<fieldset>

<legend>Pizza Size</legend>

<ul>

<li>

<label>

<input type="radio" name="size" required> Small

</label>

</li>

<li>

<label>

<input type="radio" name="size" required> Large

</label>

</li>

</ul>

</fieldset>

<fieldset>

<legend>Pizza Toppings</legend>

<ul>

<li>

<label>

<input type="checkbox" name="topping" value="bacon"> Bacon

</label>

</li>

<li>

<label>

<input type="checkbox" name="topping" value="onion"> Onion

</label>

</li>

<li>

<label>

<input type="checkbox" name="topping" value="mushroom"> Mushroom

</label>

</li>

</ul>

</fieldset>

<div>

<label>

Preferred delivery time:

<input type="time" min="11:00" max="21:00" step="900" name="delivery" required>

</label>

</div>

<div>

<label>

Delivery instructions:

<textarea name="comments"></textarea>

</label>

</div>

<div>

<button>Submit order</button>

</div>

</form>

</xmp>

It is also possible to limit the length of an input, using the <{input/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:

<xmp highlight="html">

...

<div>

<label>

Delivery instructions:

<textarea name="comments" maxlength="1000"></textarea>

</label>

</div>

<div>

<button>Submit order</button>

</div>

</form>

</xmp>

<p class="note">

When a form is submitted, <code>invalid</code> 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.

</p>

<h5 id="enabling-clientside-automatic-filling-of-form-controls">Enabling client-side automatic filling of form controls</h5>

<em>This section is non-normative.</em>

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 <{autocompleteelements/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:

<xmp highlight="html">

<form method="post" enctype="application/x-www-form-urlencoded" action="https://pizza.example.com/order">

<div>

<label>

Customer name:

<input name="custname" required autocomplete="shipping name">

</label>

</div>

<div>

<label>

Telephone:

<input type="tel" name="custtel" autocomplete="shipping tel">

</label>

</div>

<div>

<label>

E-mail:

<input type="email" name="custemail" autocomplete="shipping email">

</label>

</div>

...

</xmp>

<h5 id="the-difference-between-the-field-type-the-autofill-field-name-and-the-input-modality">The difference between the field type, the autofill field name, and the input modality</h5>

<em>This section is non-normative.</em>

The <{input/type}> and <{autocompleteelements/autocomplete}> attributes can seem confusingly

similar. For instance, in all three cases, the string "<code>email</code>" is a valid value.

This section attempts to illustrate the difference between the three attributes and provides

advice suggesting how to use them.

The <{input/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, etc.

The <{autocompleteelements/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 <code>&lt;input type="tel"&gt;</code>.

However, which <{input/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:

<xmp highlight="html">

<p>Please enter complete phone numbers including the country code prefix, as in "+1 555 123 4567".</p>

<div>

<label>

Your phone number:

<input type="tel" name="custtel" autocomplete="billing tel">

</label>

</div>

<div>

<label>

Recipient's phone number:

<input type="tel" name="shiptel" autocomplete="shipping tel">

</label>

</div>

</xmp>

But if the site only supports British customers and recipients, it might instead look like this

(notice the use of <code>tel-national</code> rather than <code>tel</code>):

<xmp highlight="html">

<p>Please enter complete UK phone numbers, as in "(01632) 960 123".</p>

<div>

<label>

Your phone number:

<input type="tel" name="custtel" autocomplete="billing tel-national">

</label>

</div>

<div>

<label>

Recipient's phone number:

<input type="tel" name="shiptel" autocomplete="shipping tel-national">

</label>

</div>

</xmp>

Now, consider a person's preferred languages. The right <{input/autocomplete}> value is

<code>language</code>. However, there could be a number of different form controls used for

the purpose: a free text field (<code>&lt;input type="text"&gt;</code>), a drop-down list

(<code>&lt;select&gt;</code>), radio buttons (<code>&lt;input type="radio"&gt;</code>), etc.

It only depends on what kind of interface is desired.

<h5 id="date-time-and-number-formats">Date, time, and number formats</h5>

<em>This section is non-normative.</em>

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 use the 24-hour clock, and 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.

<p class="note">

See also the <a>implementation notes</a> regarding localization of form controls.

</p>

<p class="warning">

In places that change from, such as Standard Time to Daylight Saving Time, the same time can

occur twice in the same day when the clocks are moved backwards.

An <{input}> element with a <{input/type}> of <code>datetime-local</code> or <code>time</code>

cannot differentiate between two identical instances of time.

If this difference matters, applications should allow users to specify which occurrence of the

duplicated time they mean, for example by choosing between "Winter time" and "Summer Time".

</p>

<h4 id="form-categories">Categories</h4>

Mostly for historical reasons, elements in this section fall into several overlapping (but

subtly different) categories in addition to the usual ones like <a>flow content</a>,

<a>phrasing content</a>, and <a>interactive content</a>.

A number of the elements are

<dfn lt="form-associated elements|form-associated">form-associated elements</dfn>,

which means they can have a <a>form owner</a>.

<ul class="brief category-list">

<li><{button}></li>

<li><{fieldset}></li>

<li><{input}></li>

<li><{label}></li>

<li><{output}></li>

<li><{select}></li>

<li><{textarea}></li>

<li><{img}></li>

</ul>

The <a>form-associated elements</a> fall into several subcategories:

<dl>

<dt><dfn lt="Listed element|Listed elements">Listed elements</dfn></dt>

<dd>

Denotes elements that are listed in the <code><var>form</var>.elements</code> and

<code><var>fieldset</var>.elements</code> APIs.

<ul class="brief category-list">

<li><{button}></li>

<li><{fieldset}></li>

<li><{input}></li>

<li><{output}></li>

<li><{select}></li>

<li><{textarea}></li>

</ul>

</dd>

<dt><dfn lt="Submittable element|Submittable elements|submittable">Submittable elements</dfn></dt>

<dd>

Denotes elements that can be used for <a>constructing the form data set</a> when a

<{form}> element is <a>submitted</a>.

<ul class="brief category-list">

<li><{button}></li>

<li><{input}></li>

<li><{select}></li>

<li><{textarea}></li>

</ul>

Some <a>submittable elements</a> can be, depending on their attributes, <dfn>buttons</dfn>.

The prose below defines when an element is a button. Some buttons are specifically

<dfn lt="submit button|submit buttons">submit buttons</dfn>.

</dd>

<dt><dfn lt="Resettable element|Resettable elements|resettable">Resettable elements</dfn></dt>

<dd>

Denotes elements that can be affected when a <{form}> element is <a>reset</a>.

<ul class="brief category-list">

<li><{input}></li>

<li><{output}></li>

<li><{select}></li>

<li><{textarea}></li>

</ul>

</dd>

<dt><dfn lt="Reassociateable element|Reassociateable elements|reassociateable">Reassociateable elements</dfn></dt>

<dd>

Denotes elements that have a <{formelements/form}> content attribute, and a

matching {{FormIDLAttribute/form}} IDL attribute, that allow authors to specify an

explicit <a>form owner</a>.

<ul class="brief category-list">

<li><{button}></li>

<li><{fieldset}></li>

<li><{input}></li>

<li><{output}></li>

<li><{select}></li>

<li><{textarea}></li>

</ul>

</dd>

</dl>

Some elements, not all of them <a>form-associated</a>, are categorized as

<dfn lt="labelable element|labelable elements|labelable">labelable elements</dfn>.

These are elements that can be associated with a <{label}> element.

<ul class="brief category-list">

<li><{button}></li>

<li><{input}> (if the <{input/type}> attribute is <em>not</em> in the <{input/Hidden}> state)</li>

<li><{meter}></li>

<li><{output}></li>

<li><{progress}></li>

<li><{select}></li>

<li><{textarea}></li>

</ul>

The following table is non-normative and summarizes the above categories of form elements:

<table class="applies">

<thead>

<tr>

<th></th>

<th>form-associated</th>

<th>listed</th>

<th>submittable</th>

<th>resettable</th>

<th>reassociateable</th>

<th>labelable</th>

</tr>

</thead>

<tbody>

<tr>

<td></td>

<td>can have a form owner</td>

<td>listed in the {{HTMLFormElement/elements|form.elements}} and {{HTMLFieldSetElement/elements|fieldset.elements}} APIs</td>

<td>can be used for constructing the form data set when a form element is submitted</td>

<td>can be affected when a form element is reset</td>

<td>have a <{formelements/form}> attribute (allows authors to specify an explicit form owner)</td>

<td>can be associated with a <{label}> element</td>

</tr>

</tbody>

<tbody>

<tr>

<td><{input}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes (except "hidden")</td>

</tr>

<tr>

<td><{button}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td>no</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{select}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{textarea}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{fieldset}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td>no</td>

<td>no</td>

<td class="yes">yes</td>

<td>no</td>

</tr>

<tr>

<td><{output}></td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td>no</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{meter}></td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{progress}></td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td class="yes">yes</td>

</tr>

<tr>

<td><{label}></td>

<td class="yes">yes</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

</tr>

<tr>

<td><{img}></td>

<td class="yes">yes</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

<td>no</td>

</tr>

</tbody>

</table>

<!-- Special thanks to Šime Vidas (https://twitter.com/simevidas) for the table content -->

<h4 id="the-form-element">The <dfn element><code>form</code></dfn> element</h4>

<dl class="element">

<dt><a>Categories</a>:</dt>

<dd><a>Flow content</a>.</dd>

<dd><a>Palpable content</a>.</dd>

<dt><a>Contexts in which this element can be used</a>:</dt>

<dd>Where <a>flow content</a> is expected.</dd>

<dt><a>Content model</a>:</dt>

<dd><a>Flow content</a>, but with no <{form}> element descendants.</dd>

<dt><a>Tag omission in text/html</a>:</dt>

<dd>Neither tag is omissible.</dd>

<dt><a>Content attributes</a>:</dt>

<dd><a>Global attributes</a></dd>

<dd><{form/accept-charset}> - Character encodings to use for [[#forms-form-submission]]</dd>

<dd><{form/action}> - [=url/URL=] to use for [[#forms-form-submission]]</dd>

<dd><{form/autocomplete}> - Default setting for autofill feature for controls in the form </dd>

<dd><{form/enctype}> - Form data set encoding type to use for [[#forms-form-submission]]</dd>

<dd><{form/method}> - HTTP method to use for [[#forms-form-submission]]</dd>

<dd><{form/name}> - Name of form to use in the {{Document/forms|document.forms}} API</dd>

<dd><{form/novalidate}> - Bypass form control validation for [[#forms-form-submission]]</dd>

<dd><{form/target}> - <a>browsing context</a> for [[#forms-form-submission]]</dd>

<dt>[=Allowed ARIA role attribute values=]:</dt>

<dd>

<a attr-value for="aria/role"><code>form</code></a> (default - <a><em>do not set</em></a>),

<a attr-value for="aria/role"><code>none</code></a>,

<a attr-value for="aria/role"><code>presentation</code></a>

or

<a attr-value for="aria/role"><code>search</code></a>.

<dt>[=Allowed ARIA state and property attributes=]:</dt>

<dd>

<a>Global aria-* attributes</a>

</dd>

<dd>

Any <code>aria-*</code> attributes

<a href="#allowed-aria-roles-states-and-properties">applicable to the allowed roles</a>.

</dd>

<dt><a>DOM interface</a>:</dt>

<dd>

<pre class="idl" data-highlight="webidl">

[OverrideBuiltins]

interface HTMLFormElement : HTMLElement {

attribute DOMString acceptCharset;

attribute DOMString action;

attribute DOMString autocomplete;

attribute DOMString enctype;

attribute DOMString encoding;

attribute DOMString method;

attribute DOMString name;

attribute boolean noValidate;

attribute DOMString target;

[SameObject] readonly attribute HTMLFormControlsCollection elements;

readonly attribute unsigned long length;

getter Element (unsigned long index);

getter (RadioNodeList or Element) (DOMString name);

void submit();

void reset();

boolean checkValidity();