An HTML form is a section of a document containing normal content,
markup, special elements called controls (checkboxes, radio buttons,
menus, etc.), and labels on those controls. Users generally "complete" a
form by modifying its controls (entering text, selecting menu items,
etc.), before submitting the form to an agent for processing (e.g., to a
Web server, to a mail server, etc.)

Here's a simple form that includes labels, radio buttons, and push
buttons submit and reset

A control's "control name" is given by its
name attribute. The scope of the name
is the FORM .

Each control has both an initial value and a current value,
which are character strings.

"initial value" may be
specified with the value attribute.TEXTAREAs initial value
is defined by its contents

<textarea>this is the iniial value</textarea>

OBJECTs initial value in a form is determined by the
object implementation.

The control's "current value" is first set
to the initial value. This may be modified through user interaction and scripts.
When a form is reset current values are reset to initial values.
If a control does not have an initial value the current-value is undefined.

(and radio buttons) are on/off switches that may be
toggled by the user. A switch is "on" when the control element's checked attribute is set.
When a form is submitted, only "on" checkbox controls can become successful.
Several checkboxes in a form may share the same control name.
Checkboxes allow several values for the same property. <INPUT
type=checkbox creates a checkbox.

radio buttons

with the same control name are
mutually exclusive: if one is "on", all others
are "off". <INPUT type=radio is
used to create a radio button.

If no radio button in a set is initially "on", user agent behavior for choosing which control is
initially "on" is undefined. One of the radio buttons in a set is
checked. If none specifies `CHECKED', then the user agent must check the
first radio button of the set initially.

menus

offer options from which to choose. The SELECT element creates a menu, in
combination with the OPTGROUP and OPTION elements.

text input

The INPUT element
creates a single-line input control and the
TEXTAREA element creates a multi-line input control. In
both cases, the input text becomes the control's current value.

file select

allows selection of files so that their
contents may be submitted with a form.

hidden controls

are not rendered but whose
values are submitted with a form. used to
control type to store information between client/server exchanges
that would otherwise be lost due to the stateless nature of HTTP
(see [RFC2616]).

generic objects in forms such that associated
values are submitted along with other controls. Authors create
object controls with the OBJECT element.

The elements used to create controls generally appear inside a FORM element, but may also appear outside of a
FORM element declaration when they are used to
build user interfaces. This is discussed in the section on intrinsic events. controls
outside a form cannot be successful controls.

list of character encodings
for input data that is accepted by the server processing this form.
The value is a space- and/or comma-delimited list of charset values. The client
must interpret this list as an exclusive-or list, i.e., the server
is able to accept any single character encoding per entity received.

The default value for this attribute is the reserved string
"UNKNOWN". User agents may interpret this value as the character
encoding that was used to transmit the document containing this FORM element.

a comma-separated list of content types
that a server processing this form will handle correctly. User
agents may use this information to filter out non-conforming files
when prompting a user to select files to be sent to the server (cf.
the INPUT element when type="file").

names the element so that it may be referred to
from style sheets or scripts. Note. This attribute
has been included for backwards compatibility. Applications should
use the id attribute to
identify elements.

The program that will handle the completed and submitted form (the
action attribute). The receiving program
must be able to parse name/value pairs in order to make use of
them.

The method by which user data will be sent to the server (the method attribute).

A character encoding that must be accepted by the server in order
to handle this form (the accept-charset
attribute). User agents may advise the user of the value of the accept-charset attribute and/or restrict the
user's ability to enter unrecognized characters.

A form can contain text and markup (paragraphs, lists, etc.) in
addition to form controls.

The following example shows a form that is to be processed by the
"adduser" program when submitted. The form will be sent to the program
using the HTTP "post" method.

tells the user agent the initial width of the
control. The width is given in pixels except when type attribute has the value "text"
or "password". In that case, its value refers to the (integer)
number of characters.

When the type attribute
has the value "text" or "password", this attribute specifies the
maximum number of characters the user may enter. This number may
exceed the specified size, in which
case the user agent should offer a scrolling mechanism. The default
value for this attribute is an unlimited number.

Like "text", but the
input text is rendered in such a way as to hide the characters
(e.g., a series of asterisks). This control type is often used for
sensitive input such as passwords. Note that the current value is the text
entered by the user, not the text rendered by the user agent.

Note. Application
designers should note that this mechanism affords only light
security protection. Although the password is masked by user agents
from casual observers, it is transmitted to the server in clear
text, and may be read by anyone with low-level access to the
network.

Creates a graphical submit button.
The value of the
src attribute specifies the URI of the image that will
decorate the button. For accessibility reasons, authors should
provide alternate
text for the image via the alt attribute.

When a
pointing device is used to click on the image, the form
is submitted and the click coordinates passed to the server. The x
value is measured in
pixels from the left of the image, and the y value in pixels from the top of the
image. The submitted data includes name.x=x-value
and name.y=y-value where "name" is the
value of the name attribute, and
x-value and y-value are the x and y coordinate
values, respectively.

If the server takes different actions depending on the location
clicked, users of non-graphical browsers will be disadvantaged. For
this reason, authors should consider alternate approaches:

Use multiple submit buttons (each with its own image) in
place of a single graphical submit button. Authors may use
style sheets to control the positioning of these buttons.

The following sample HTML fragment defines a simple form that allows
the user to enter a first name, last name, email address, and gender.
When the submit button is activated, the form will be sent to the program
specified by the action attribute.

Please consult the section on intrinsic events for more information
about scripting and events.

The following example shows how the contents of a user-specified file
may be submitted with a form. The user is prompted for his or her name
and a list of file names whose contents should be submitted with the
form. By specifying the enctype value of
"multipart/form-data", each file's contents will be packaged for
submission in a separate section of a multipart document.

Buttons created with the BUTTON element function
just like buttons created with the INPUT element, but they
offer richer rendering possibilities: the BUTTON element may have content. For example, a
BUTTON element that contains an image functions
like and may resemble an INPUT element whose type is set to "image", but the BUTTON element type allows content.

Visual user agents may render BUTTON buttons with relief
and an up/down motion when clicked, while they may render INPUT buttons as "flat" images.

The following example expands a previous example, but creates submit and reset
buttons with BUTTON instead of INPUT. The buttons contain images by way of the
IMG element.

If a SELECT element is presented as a scrolled
list box, this attribute specifies the number of rows in the list
that should be visible at the same time. Visual user agents are not
required to present a SELECT element as a
list box; they may use any other mechanism, such as a drop-down
menu.

The SELECT element creates a menu. Each choice offered by the menu is represented by
an OPTION element. A SELECT element must contain at least one OPTION element.

The OPTGROUP element allows authors to group
choices logically. This is particularly helpful when the user must choose
from a long list of options; groups of related choices are easier to
grasp and remember than a single long list of options. In HTML 4, all
OPTGROUP elements must be specified directly within a SELECT element (i.e., groups may not be
nested).

Zero or more choices may be pre-selected for the user. User agents
should determine which choices are pre-selected as follows:

If no OPTION element has the selected attribute set, user agent behavior
for choosing which option is initially selected is undefined.
Note. Since existing implementations handle this
case differently, the current specification differs from RFC 1866 ([RFC1866] section 8.1.3), which states:

The initial state has the first option selected, unless a SELECTED
attribute is present on any of the <OPTION>
elements.

Since user agent behavior differs, authors should ensure that each
menu includes a default pre-selected OPTION.

If one OPTION element has the selected attribute set, it should be
pre-selected.

If the SELECT element has the multiple attribute set and more than one
OPTION element has the selected attribute set,
they should all be pre-selected.

It is considered an error if more than one OPTION element has the
selected attribute set and the SELECT element does not have the
multiple attribute set. User agents may vary in how they
handle this error, but should not pre-select more than one
choice.

Note. Implementors are advised that future
versions of HTML may extend the grouping mechanism to allow for nested
groups (i.e., OPTGROUP elements may nest). This will allow
authors to represent a richer hierarchy of choices.

This attribute allows authors to specify a shorter label for an
option than the content of the OPTION element. When
specified, user agents should use the value of this attribute
rather than the content of the OPTION element as the
option label.

The label attribute of the
OPTGROUP element specifies the label for a group of
choices.

In this example, we create a menu that allows the user to select which
of seven software components to install. The first and second components
are pre-selected but may be deselected by the user. The remaining
components are not pre-selected. The size attribute states that the menu
should only have 4 rows even though the user may select from among 7
options. The other options should be made available through a scrolling
mechanism.

Only selected options will be successful (using the control name "component-select"). When no
options are selected, the control is not successful and neither the name
nor any values are submitted to the server when the form is submitted.
Note that where the value attribute is
set, it determines the control's initial
value, otherwise it's the element's contents.

In this example we use the OPTGROUP element to group
choices. The following markup:

Visual user
agents may allow users to select from option groups through a
hierarchical menu or some other mechanism that reflects the structure of
choices.

A graphical user agent might render this as:

This image shows a SELECT element rendered as
cascading menus. The top label of the menu displays the currently
selected value (PortMaster 3, 3.7.1). The user has unfurled two cascading
menus, but has not yet selected the new value (PortMaster 2, 3.7). Note
that each cascading menu displays the label of an
OPTGROUP or OPTION element.

This attribute specifies the number of visible text lines. Users
should be able to enter more lines than this, so user agents should
provide some means to scroll through the contents of the control
when the contents extend beyond the visible area.

This attribute specifies the visible width in average character
widths. Users should be able to enter longer lines than this, so
user agents should provide some means to scroll through the
contents of the control when the contents extend beyond the visible
area. User agents may wrap visible text lines to keep long lines
visible without the need for scrolling.

Setting the readonly attribute allows authors to display
unmodifiable text in a TEXTAREA. This differs from
using standard marked-up text in a document because the value of TEXTAREA is submitted with the form.

Semantics of ISINDEX.
Currently, the semantics for ISINDEX are only
well-defined when the base URI for the enclosing document is an HTTP URI.
In practice, the input string is restricted to Latin-1 as there is no
mechanism for the URI to specify a different character
set.

This attribute explicitly associates the label being defined with
another control. When present, the value of this attribute must be
the same as the value of the id attribute of some other control in the
same document. When absent, the label being defined is associated
with the element's contents.

The LABEL element may be used to attach information
to controls. Each LABEL element is associated with exactly one
form control.

The for attribute associates a label with
another control explicitly: the value of the for attribute must be the same as the value of
the id attribute of the associated control element.
More than one LABEL may be associated with the same control
by creating multiple references via the for attribute.

This example creates a table that is used to align two text input controls and their associated labels.
Each label is associated explicitly with one text
input:

To associate a
label with another control implicitly, the control element
must be within the contents of the LABEL element. In this
case, the LABEL may only contain one control element. The
label itself may be positioned before or after the associated control.

In this example, we implicitly associate two labels with two text input controls:

The FIELDSET element allows authors to group
thematically related controls and labels. Grouping controls makes it
easier for users to understand their purpose while simultaneously
facilitating tabbing navigation for visual user agents and speech
navigation for speech-oriented user agents. The proper use of this
element makes documents more accessible.

The LEGEND element allows authors to assign a
caption to a FIELDSET. The legend improves accessibility
when the FIELDSET is rendered non-visually.

In this example, we create a form that one might fill out at the
doctor's office. It is divided into three sections: personal information,
medical history, and current medication. Each section contains controls
for inputting the appropriate information.

Note that in this example, we might improve the visual presentation of
the form by aligning elements within each FIELDSET (with style sheets), adding color and
font information (with style sheets), adding scripting (say, to only open
the "current medication" text area if the user indicates he or she is
currently on medication), etc.

Example:

<body onLoad="document.formname.controlname.focus();" >

In an HTML document, an element must receive focus from the
user * in order to become active and perform its tasks. For example, users
must activate a link specified by the A element in order to follow the specified link.
Similarly, users must give a TEXTAREA focus in order to
enter text into it.

There are several ways to give focus to an element:

Designate the element with a pointing device.

Navigate from one element to the next with the keyboard. The
document's author may define a tabbing order that specifies
the order in which elements will receive focus if the user navigates
the document with the keyboard (see tabbing navigation). Once selected, an
element may be activated by some other key sequence.

Select an element through an access
key (sometimes called "keyboard shortcut" or "keyboard
accelerator").

specifies the position of the current element in the tabbing order, must be a
number between 0 and 32767. User agents should ignore leading zeros.

The tabbing order defines
the order in which elements will receive focus when navigated by the user
via the keyboard.
The tabbing order may include elements nested within other elements.

Values need not be sequential nor must they begin with any particular value.

The initial position of the cursor is not defined by any TABINDEX.

Elements that may receive focus should be navigated by user agents according to the rules:

Those elements that support the tabindex attribute and
assign a positive value to it are navigated first, from the element with the lowest tabindex value.
Elements that have identical tabindex values should be navigated in the
order they appear in the character stream.

Those elements that do not support the tabindex attribute or
support it and assign it a value of "0" are navigated next in the order they appear in the character stream.

In this example, the tabbing order will be the BUTTON, the INPUT elements in order
(note that "field1" and the button share the same tabindex, but "field1"
appears later in the character stream), and finally the link created by
the A element.

Tabbing keys. The actual key sequence that causes
tabbing navigation or element activation depends on the configuration of
the user agent (e.g., the "tab" key is used for navigation and the
"enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the tabbing
order in reverse. When the end (or beginning) of the tabbing order is
reached, user agents may circle back to the beginning (or end).

This attribute assigns an access key to an element. An access key is a single character from
the document character set. Note. Authors should
consider the input method of the expected reader when specifying an
accesskey.

Pressing an access key
assigned to an element gives focus to the element. The action
that occurs when an element receives focus depends on the element. For
example, when a user activates a link defined by the
A element, the user agent generally follows the link. When a
user activates a radio button, the user agent changes the value of the
radio button. When the user activates a text field, it allows input,
etc.

This example assigns the access key "U" to a label associated with an
INPUT control. Typing the access key gives focus to the label
which in turn gives it to the associated control. The user may then enter
text into the INPUT area.

The invocation of access keys depends on the underlying system. For
instance, on machines running MS Windows, one generally has to press the
"alt" key in addition to the access key. On Apple systems, one generally
has to press the "cmd" key in addition to the access key.

The rendering of access keys depends on the user agent. We recommend
that authors include the access key in label text or wherever the access
key is to apply. User agents should render the value of an access key in
such a way as to emphasize its role and to distinguish it from other
characters (e.g., by underlining it).

In contexts where user input is either undesirable or irrelevant, it
is important to be able to disable a control or render it read-only. For
example, one may want to disable a form's submit button until the user
has entered some required data. Similarly, an author may want to include
a piece of read-only text that must be submitted as a value along with
the form. The following sections describe disabled and read-only
controls.

For radio buttons that share the same value of
the name attribute, only the "on" radio
button may be successful.

For menus, the control
name is provided by a SELECT element and
values are provided by OPTION elements. Only
selected options may be successful. When no options are selected, the
control is not successful and neither the name nor any values are
submitted to the server when the form is submitted.

The current value of a file select is a list of one or more file
names. Upon submission of the form, the contents of each
file are submitted with the rest of the form data. The file contents
are packaged according to the form's content type.

The current value of an object control is determined by the
object's implementation.

If a control doesn't have a current value
when the form is submitted, user agents are not required to treat it as a
successful control.

Furthermore, user agents should not consider the following controls
successful:

Finally, the encoded data is sent to the processing agent designated
by the action attribute using the protocol specified
by the method attribute.

This specification does not specify all valid submission methods or content types that may be used with forms.
However, HTML 4 user agents must support the established conventions in
the following cases:

If the method is "get" and the action is an HTTP URI, the user agent takes
the value of action, appends a `?' to it,
then appends the form data set, encoded
using the "application/x-www-form-urlencoded" content type. The user agent then
traverses the link to this URI. In this scenario, form data are
restricted to ASCII codes.

If the method is "post" and the action is an HTTP URI, the user agent
conducts an HTTP "post" transaction using the value of the action attribute and a message created
according to the content type
specified by the enctype attribute.

The enctype attribute of the FORM element specifies the content type used to encode
the form data set for submission to the
server. User agents must support the content types listed below. Behavior
for other content types is unspecified.

This is the default content type. Forms submitted with this content
type must be encoded as follows:

Control names and values are escaped. Space characters are replaced
by `+', and then reserved characters are escaped as
described in [RFC1738],
section 2.2: Non-alphanumeric characters are replaced by
`%HH', a percent sign and two hexadecimal digits representing
the ASCII code of the character. Line breaks are represented as "CR
LF" pairs (i.e., `%0D%0A').

The control names/values are listed in the order they appear in the
document. The name is separated from the value by `='
and name/value pairs are separated from each other by
`&'.

The content type "application/x-www-form-urlencoded" is inefficient
for sending large quantities of binary data or text containing non-ASCII
characters. The content type "multipart/form-data" should be used for
submitting forms that contain files, non-ASCII data, and binary data.

The content "multipart/form-data" follows the rules of all multipart
MIME data streams as outlined in [RFC2045]. The
definition of "multipart/form-data" is available at the [IANA]
registry.

A "multipart/form-data" message contains a series of parts, each
representing a successful control. The
parts are sent to the processing agent in the same order the
corresponding controls appear in the document stream. Part boundaries
should not occur in any of the data; how this is done lies outside the
scope of this specification.

As with all multipart MIME types, each part has an optional
"Content-Type" header that defaults to "text/plain". User agents should
supply the "Content-Type" header, accompanied by a "charset"
parameter.

Each part is expected to contain:

a "Content-Disposition" header whose value is "form-data".

a name attribute specifying the control
name of the corresponding control. Control names originally
encoded in non-ASCII character sets may
be encoded using the method outlined in [RFC2045].

Thus, for example, for a control named "mycontrol", the corresponding
part would be specified:

Content-Disposition: form-data; name="mycontrol"

As with all MIME transmissions, "CR LF" (i.e., `%0D%0A')
is used to separate lines of data.

Each part may be encoded and the "Content-Transfer-Encoding" header
supplied if the value of that part does not conform to the default (7BIT)
encoding (see [RFC2045], section 6)

If the contents of a file are submitted with a form, the file input
should be identified by the appropriate content type (e.g.,
"application/octet-stream"). If multiple files are to be returned as the
result of a single form entry, they should be returned as
"multipart/mixed" embedded within the "multipart/form-data".

The user agent should attempt to supply a file name for each submitted
file. The file name may be specified with the "filename" parameter of the
'Content-Disposition: form-data' header, or, in the case of multiple
files, in a 'Content-Disposition: file' header of the subpart. If the
file name of the client's operating system is not in US-ASCII, the file
name might be approximated or encoded using the method of [RFC2045]. This is convenient for those cases where,
for example, the uploaded files might contain references to each other
(e.g., a TeX file and its ".sty" auxiliary style description).

The following example illustrates "multipart/form-data" encoding.
Suppose we have the following form: