Forms 

Contents

  1. The FORM element
  2. Controls
    1. The INPUT element
    2. The BUTTON element
    3. The SELECT and OPTION elements
    4. The TEXTAREA element
    5. The LABEL element
    6. The FIELDSET and LEGEND elements
  3. Giving focus to an element
    1. Tabbing navigation
    2. Access keys
  4. Disabled and read-only elements
    1. Disabled elements
    2. Read-only elements
  5. Form submission
    1. Which element values are submitted

An HTML form is a section of a document containing normal content, markup, and special elements called controls. Controls respond to and accept user input. Users generally "complete" forms by entering text, selecting menu items, etc., and then submitting the form for processing. Submitted forms may either be mailed to another user or fed to a program for treatment.

Controls may be check boxes, radio buttons, labels, menus, etc. Each control may be assigned a name. When the form is submitted, some controls (depending on their state) have their name and current value submitted along with the form. The nature of the value submitted depends on the control (e.g., the value of a text box is the input text).

Note: This specification includes more detailed information about forms in sections on form display issues. Further information on encoding form contents is expected to be added in later revisions to this draft.

The FORM element 

<!ELEMENT FORM - - %block -(FORM)>
<!ATTLIST FORM
  %attrs;                          -- %coreattrs, %i18n, %events --
  action      %URL       #REQUIRED -- server-side form handler --
  method      (GET|POST) GET       -- HTTP method used to submit the form --
  enctype     %ContentType; "application/x-www-form-urlencoded"
  onsubmit    %Script    #IMPLIED  -- the form was submitted --
  onreset     %Script    #IMPLIED  -- the form was reset --
  target      CDATA      #IMPLIED  -- where to render result --
  accept-charset CDATA   #IMPLIED  -- list of supported charsets --
  >

Start tag: required, End tag: required

Attribute definitions

action = url
This attribute specifies a program for handling the submitted form. It may be an HTTP URL (to submit the form to a program) or a MAILTO URL (to email the form).
method = get|post
This attribute specifies which HTTP method will be used to submit name/value pairs to the form handler. The Possible values:
  • post: Use the HTTP POST method. The POST method includes name/value pairs in the body of the form and not in the URL specified by the action attribute.
  • get:Deprecated. Use the HTTP GET method. The GET method appends name/value pairs to the URL specified by action and sends this new URL to the server. This is the default value for backwards compatibility. This value has been deprecated for reasons of internationalization.
enctype = cdata
This attribute specifies the Internet Media Type (see [MIMETYPES]) used to submit the form to the server (when the value of method is "post"). The default value for this attribute is "application/x-www-form-urlencoded". The value "multipart/form-data" should be used when the returned document includes submitted files.
accept-charset = cdata
This attribute specifies the list of character encodings for input data that must be accepted by the server processing this form. The value is a space and/or comma-delimited list of "charsets" as defined in [RFC2045]. The server must interpret this list as an exclusive-or list, i.e., the server must be 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.

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

Attributes defined elsewhere

The FORM element acts as a container for controls. It specifies:

A form can contain text and markup (paragraphs, lists, etc.) as well as the controls listed below.

The scope of the name attribute for any controls within a FORM element is the FORM element.

The following example specifies that the submitted form will be processed by the "adduser" program. The form will be sent to the program using the HTTP POST method.

 <FORM action="http://somesite.com/prog/adduser" method="post">
 ...form contents...
 </FORM>

The following example shows how to send a submitted form to an email address.

 <FORM action="mailto:Kligor.T@gee.whiz.com" method="post">
 ...form contents...
 </FORM>

Controls 

The following control elements generally appear within a FORM element declaration. However, these elements may also appear outside of a FORM element declaration when they are used to build user interfaces. This is discussed later in this specification, in the section on intrinsic events.

Control labels
Some form controls automatically have labels associated with them (press buttons created by INPUT and BUTTON) while most do not (text fields created by INPUT and TEXTAREA, checkboxes and radio buttons created by INPUT, and menus created by SELECT).

For those controls that have implicit labels, user agents should take the value of the value attribute for the label string.

For those controls without implicit labels, authors must provide labels before or after the control element's definition. This is illustrated in the examples below.

The INPUT element 

<!ENTITY % InputType
  "(TEXT | PASSWORD | CHECKBOX |
    RADIO | SUBMIT | RESET |
    FILE | HIDDEN | IMAGE | BUTTON)"
   >

<!-- HSPACE and VSPACE missing due to lack of widespread support -->
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
  %attrs;                          -- %coreattrs, %i18n, %events --
  type      %InputType   TEXT      -- what kind of widget is needed --
  name        CDATA      #IMPLIED  -- required for all but submit & reset --
  value       CDATA      #IMPLIED  -- required for radio and checkboxes --
  checked   (checked)    #IMPLIED  -- for radio buttons and check boxes --
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  readonly  (readonly)   #IMPLIED  -- for text and passwd --
  size        CDATA      #IMPLIED  -- specific to each type of field --
  maxlength   NUMBER     #IMPLIED  -- max chars for text fields --
  src         %URL       #IMPLIED  -- for fields with images --
  alt         CDATA      #IMPLIED  -- description for text only browsers --
  usemap      %URL       #IMPLIED  -- use client-side image map --
  align       %IAlign    #IMPLIED  -- vertical or horizontal alignment --
  tabindex    NUMBER     #IMPLIED  -- position in tabbing order --
  onfocus     %Script    #IMPLIED  -- the element got the focus --
  onblur      %Script    #IMPLIED  -- the element lost the focus --
  onselect    %Script    #IMPLIED  -- some text was selected --
  onchange    %Script    #IMPLIED  -- the element value was changed --
  accept      CDATA      #IMPLIED  -- list of MIME types for file upload --
  >

Start tag: required, End tag: forbidden

Attribute definitions

type = text|password|checkbox|radio|submit|reset|file|hidden|image|button
This attribute specifies the type of input control to create. We discuss input control types below. The default value for this attribute is "text".
name = cdata
This attribute assigns a name to the control. This name will be paired with the current value of the control if the element's value is submitted along with the form.
value = cdata
This attribute specifies the initial value of the control. It is optional except when the control type is "radio".
size = cdata
This attribute tells the user agent the initial width of the control. The width is given in pixels, except for control types "text" and "password" when it is the (integer) number of characters.
maxlength = integer
When the control type is "text" or "password", this attribute specifies the maximum number of characters that may be entered. 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.
checked
When the control type is "radio", this boolean attribute specifies that the radio button is on. This attribute must be ignored for other control types.
src = url
When the control type is "image", this attribute specifies the location of the image to be used to decorate the graphical submit button.

Attributes defined elsewhere

The nature of a control defined by the INPUT element depends on the value of the type attribute.

Input types 

The INPUT element's type attribute determines which control will be created.

text
This type creates a single-line text box. The value submitted by a text control is the input text.
password
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 is used for sensitive input such as passwords. The value submitted by a password control is the input text (not the rendering).
checkbox
A checkbox is an on/off switch. When the switch is on, the value of the checkbox is "active". When the switch is off, the value is inactive. The checkbox value is only submitted with the form when the switch is on.

Several checkboxes within the same form may bear the same name. Upon submission, each "on" checkbox with the same name submits a name/value pair with the same name component. This allows users to select more than one value for a given property.

radio
A radio button is an on/off switch. When the switch is on, the value of the radio button is "active". When the switch is off, the value is inactive. The radio button value is only submitted with the form when the switch is on.

Several radio button within the same form may bear the same name. However, only one of these buttons may be "on" at any one time. All related buttons are set to "off" as soon as one is set to "on". Thus, for related radio buttons, only one name/value pair is ever submitted.

submit
Creates a submit button. When this button is activated by the user, the form is submitted to the location specified by the action attribute of the englobing FORM element.

A form may contain more than one submit button. Only the name/value pair of the activated submit button is submitted with the form.

image
Creates a graphical submit button. The value of the src attribute specifies the URL of the image that will decorate the button. Some users will be unable to see this image. We strongly recommend you provide a value for the alt attribute as an textual alternative for the image.

When a pointing device is used to click on the image, the form is submitted and the location 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, you are recommended to consider alternative approaches:

A possible future extension would be to add the usemap attribute to INPUT for use as as client-side image map when "type=image". The AREA element corresponding to the location clicked would contribute the value to be passed to the server. To avoid the need to modify server scripts, it may be appropriate to extend AREA to provide x and y values for use with the INPUT element.

reset
Creates a reset button. When this button is activated by the user, all of the form's controls have their values reset to the initial values specified by their value attributes. The name/value for a reset button are not submitted with the form.
button
Creates a push button that has no default behavior. The behavior of the button is defined by associating the button with client-side scripts that are triggered when events affecting the button occur (e.g., clicking the button). The value of the value attribute is the label used for the button.

For example, the following declaration causes the function named verify to be executed when the button is clicked. The script must be defined by a SCRIPT element.

<INPUT type="button" value="Click Me" onclick="verify()">

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

hidden
Creates a element that is not rendered by the user agent. However, the element's name and value are submitted with the form.

This control type is generally used to store information between client/server exchanges that would otherwise be loss due to the stateless nature of HTTP.

INPUT controls of type hidden have their values submitted with the form. The same holds for controls that are not rendered because of style information. The following control, though hidden by the user agent, will have its value submitted with the form.

<INPUT type="password" style="display:none"  
          name="invisible-password"
          value="mypassword">
file
Prompts the user for a file name. When the form is submitted, the contents of the file are submitted to the server as well as other user input.

User agents should encapsulate multiple files in a MIME multipart document (see [RFC2045]). This mechanism encapsulates each file in a a body-part of a multipart MIME body that is sent as the HTTP entity. Each each body part can be labeled with an appropriate "Content-Type", including if necessary a "charset" parameter that specifies the character encoding.

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

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>
    First name: <INPUT type="text" name="firstname"><BR>
    Last name: <INPUT type="text" name="lastname"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>
    <INPUT type="submit" value="Send"> <INPUT type="reset">
 </FORM>

This form might be rendered as follows:

An example form rendering.

In the section on the LABEL element, we discuss marking up labels such as "First name".

The following example shows how the contents of a user-specified file may be submitted with a form. This example is based on an example from [RFC1867].

In this example, the user is prompted to enter a name and a list of names of files whose contents should be submitted with the form. By specifying the enctype value of "multipart/form-data", each file's contents are stored in a separate section of a multipart document.

<FORM action="http://server.dom/cgi/handle"
    enctype="multipart/form-data"
    method="post">
 What is your name? <INPUT type="text" name="name_of_sender">
 What files are you sending? <INPUT type="file" name="name_of_files">
</FORM>

Please consult [RFC1867] for more information about file submissions.

The ISINDEX element 

ISINDEX is deprecated. Users should use the INPUT element instead of this element.

<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
  %coreattrs;                      -- id, class, style, title --
  %i18n;                           -- lang, dir --
  prompt      CDATA      #IMPLIED  -- prompt message -->

Start tag: required, End tag: forbidden

Attribute definitions

prompt = cdata
Deprecated. This attribute specifies a prompt string for the input field.

Attributes defined elsewhere

The ISINDEX element causes the user agent to prompt the user for a single line of input (allowing any number of characters). The user agent may use the value of the prompt attribute as a title for the prompt.

DEPRECATED EXAMPLE:
The following ISINDEX declaration:

<ISINDEX prompt="Enter your search phrase: ">

is equivalent to the following INPUT declaration:

<FORM action="..." method="post">
Enter your search phrase: <INPUT type="text">
</FORM>

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

The BUTTON element  

<!ELEMENT BUTTON - -
     (%inline | %blocklevel)* -(A | %formctrl | FORM | ISINDEX | FIELDSET)>
<!ATTLIST BUTTON
  %attrs;                          -- %coreattrs, %i18n, %events --
  name        CDATA      #IMPLIED  -- for scripting/forms as submit button --
  value       CDATA      #IMPLIED  -- gets passed to server when submitted --
  type    (submit|reset) #IMPLIED  -- for use as form submit/reset button --
  disabled   (disabled)  #IMPLIED  -- control is unavailable in this context --
  tabindex    NUMBER     #IMPLIED  -- position in tabbing order --
  onfocus     %Script    #IMPLIED  -- the element got the focus --
  onblur      %Script    #IMPLIED  -- the element lost the focus --
  >

Start tag: required, End tag: required

Attribute definitions

name = cdata
This attribute assigns a name to the button.
value = cdata
This attribute assigns a value to the button.
type = button|submit|reset
This attribute declares the type of the button. When this attribute is not set, the button's behavior is undefined. Possible values:
  • button: Creates a simple push button intended to trigger a script.
  • submit: Creates a button that submits an englobing form. This is the default value.
  • reset: Creates a button that resets an englobing form.

Attributes defined elsewhere

A BUTTON element whose type is "submit" is very similar to an INPUT element whose type is "submit". They both cause a form to be submitted, but the BUTTON element allows richer presentational possibilities.

A BUTTON element whose type is "submit" and whose content is an image (e.g., the IMG element) is very similar to an INPUT element whose type is "image". They both cause a form to be submitted, but their presentation is different. In this context, an INPUT element is supposed to be rendered as a "flat" image, while a BUTTON is supposed to be rendered as a button (e.g., with relief and an up/down motion when clicked).

The following example expands a previous example by substituting the INPUT elements that create submit and reset buttons with button BUTTON instances. The buttons contain images by way of the IMG element.

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>
    First name: <INPUT type="text" name="firstname"><BR>
    Last name: <INPUT type="text" name="lastname"><BR>
    email: <INPUT type="text" name="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>
    <BUTTON name="submit" value="submit" type="submit">
    Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
    <BUTTON name="reset" type="reset">
    Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
 </FORM>

If a BUTTON is used with an IMG element, you are recommended to exploit the IMG element's alt attribute to provide a description for users unable to see the image.

It is illegal to associate an image map with an IMG that appears as the contents of a BUTTON element.

ILLEGAL EXAMPLE:
The following is not considered legal HTML.

<BUTTON>
<IMG src="foo.gif" usemap="...">
</BUTTON>

A BUTTON element whose type is "reset" is very similar to an INPUT element whose type is "reset". They both cause controls to regain their initial values, but the BUTTON element allows richer presentation.

The BUTTON element may also be used together with scripts, in which case it's type should be "button". When such a button is activated, a client-side script is executed. We discuss this use of BUTTON later in the specification in the section on intrinsic events.

The SELECT and OPTION elements 

<!ELEMENT SELECT - - (OPTION+)>
<!ATTLIST SELECT
  %attrs;                          -- %coreattrs, %i18n, %events --
  name        CDATA      #REQUIRED -- field name --
  size        NUMBER     #IMPLIED  -- rows visible --
  multiple  (multiple)   #IMPLIED  -- default is single selection --
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  tabindex    NUMBER     #IMPLIED  -- position in tabbing order --
  onfocus     %Script    #IMPLIED  -- the element got the focus --
  onblur      %Script    #IMPLIED  -- the element lost the focus --
  onselect    %Script    #IMPLIED  -- some text was selected --
  onchange    %Script    #IMPLIED  -- the element value was changed --
  >

Start tag: required, End tag: required

SELECT Attribute definitions

name = cdata
This attribute assigns a name to the element. This name will be paired with any selected values when the form is submitted.
size = integer
This attribute specifies the number of rows to be rendered by the user agent. The number of rows may be smaller than the number of possible choices. In this case, the user agent should provide a scrolling mechanism for accessing all possible choices.
multiple
When set, this boolean attribute allows multiple selections. When not set, the SELECT element only permits single selections. Traditionally, visual user agents render multiple-selection elements as list boxes, while single-selection elements are rendered as drop-down menus.

The SELECT element creates a list of choices that may be selected by the user. Each SELECT element must contain at least one choice. Each choice is specified by an instance of the OPTION element.

<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
  %attrs;                          -- %coreattrs, %i18n, %events --
  selected  (selected)   #IMPLIED
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  value       CDATA      #IMPLIED  -- defaults to element content --
  >

Start tag: required, End tag: optional

OPTION Attribute definitions

selected
When set, this boolean attribute specifies that this option is selected (initially or by the user).
value = cdata
This attribute specifies the value to be submitted for this choice if the choice is selected when the form is submitted. The value is paired with the name assigned to the SELECT element. If this attribute is not set, the submitted value defaults to the content of the OPTION element.

Attributes defined elsewhere

User agents should use the content of the OPTION element as the displayed choice.

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 initially selected but may be deselected by the user. The remaining components are not initially 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 must be made available through a scrolling mechanism.

The SELECT is followed by submit and reset buttons.

<FORM action="http://somesite.com/prog/component-select" method="post">
   <SELECT multiple size="4" name="component-select">
      <OPTION selected value="Component_1_a">Component_1</OPTION>
      <OPTION selected value="Component_1_b">Component_2</OPTION>
      <OPTION>Component_3</OPTION>
      <OPTION>Component_4</OPTION>
      <OPTION>Component_5</OPTION>
      <OPTION>Component_6</OPTION>
      <OPTION>Component_7</OPTION>
   </SELECT>
   <INPUT type="submit" value="Send"><INPUT type="reset">
</FORM>

When the form is submitted, each selected choice will be paired with the name "component-select" and submitted. The submitted value of each OPTION will be its contents, except where overridden by the value attribute (here, in the first two components).

The TEXTAREA element 

<!ELEMENT TEXTAREA - - (#PCDATA)*>
<!ATTLIST TEXTAREA
  %attrs;                          -- %coreattrs, %i18n, %events --
  name        CDATA      #REQUIRED
  rows        NUMBER     #REQUIRED
  cols        NUMBER     #REQUIRED
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  readonly  (readonly)   #IMPLIED
  tabindex    NUMBER     #IMPLIED  -- position in tabbing order --
  onfocus     %Script    #IMPLIED  -- the element got the focus --
  onblur      %Script    #IMPLIED  -- the element lost the focus --
  onselect    %Script    #IMPLIED  -- some text was selected --
  onchange    %Script    #IMPLIED  -- the element value was changed --
  >

Start tag: required, End tag: required

Attribute definitions

name = cdata
This attribute assigns a name to the element. This name will be paired with the content of the element when submitted to the server.
rows = integer
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 textarea field when the contents extend beyond the visible area.
cols = integer
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 textarea field 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.

Attributes defined elsewhere

The TEXTAREA element creates a multi-line text input control (as opposed to a single-line INPUT control). The content of this element provides the initial text presented by the control.

This example creates a TEXTAREA control that is 20 rows by 80 columns and contains two lines of text initially. The TEXTAREA is followed by submit and reset buttons.

<FORM action="http://somesite.com/prog/text-read" method="post">
   <TEXTAREA rows="20" cols="80">
   First line of initial text.
   Second line of initial text.
   </TEXTAREA>
   <INPUT type="submit" value="Send"><INPUT type="reset">
</FORM>

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.

It is recommended that user agents canonicalize line endings to CR, LF (ASCII decimal 13, 10) when submitting the field's contents. The character set for submitted data should be ISO Latin-1, unless the server has previously indicated that it can support alternative character sets.

The LABEL element 

<!ELEMENT LABEL - - (%inline)* -(LABEL) -- field label text -->
<!ATTLIST LABEL
  %attrs;                          -- %coreattrs, %i18n, %events --
  for         IDREF      #IMPLIED  -- matches field ID value --
  disabled    (disabled) #IMPLIED  -- control is unavailable in this context --
  accesskey   CDATA      #IMPLIED  -- accessibility key character --
  onfocus     %Script    #IMPLIED  -- the element got the focus --
  onblur      %Script    #IMPLIED  -- the element lost the focus --
  >

Start tag: required, End tag: required

Attribute definitions

for = control-name
This attribute explicitly associates the label being defined with another control. The value of this attribute must be the value of the id attribute of some other control in the same document. In the absence of this attribute, the label being defined is associated with its contents.

Attributes defined elsewhere

The LABEL element may be used to attach information to other control elements (excluding other LABEL elements). Labels may be rendered by user agents in a number of ways (e.g., visually, read by speech synthesizers, etc.)

When a LABEL element receives focus, it passes the focus on to its associated control. See the section below on access keys for examples.

To associate a label with another control explicitly, set the for attribute of the LABEL.

This example creates a table that is used to align two INPUT controls and their associated labels. Each label is associated explicitly with one of the INPUT elements.

<FORM action="..." method="post">
<TABLE>
  <TR>
    <TD><LABEL for="fname">First Name</LABEL>
    <TD><INPUT type="text" name="firstname" id="fname">
  <TR>
    <TD><LABEL for="lname">Last Name</LABEL>
    <TD><INPUT type="text" name="lastname" id="lname">
</TABLE>
<FORM>

This example extends a previous example form to include LABEL elements. Note that the LABEL elements are associated to the INPUT elements through the id attribute.

 <FORM action="http://somesite.com/prog/adduser" method="post">
    <P>
    <LABEL for="firstname">First name: </LABEL><INPUT 
              type="text" id="firstname"><BR>
    <LABEL for="lastname">Last name: </LABEL><INPUT 
              type="text" id="lastname"><BR>
    <LABEL for="email"email: </LABEL><INPUT 
              type="text" id="email"><BR>
    <INPUT type="radio" name="sex" value="Male"> Male<BR>
    <INPUT type="radio" name="sex" value="Female"> Female<BR>
    <INPUT type="submit" value="Send"> <INPUT type="reset">
 </FORM>

More than one LABEL may be associated with the same control by creating multiple references via the for attribute.

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

In this example, we implicitly associate two labels and two INPUT elements. Notice that the implicit association prevents us from being able to layout the label and its associated control in a table (see the previous example).

<FORM action="..." method="post">
<LABEL>
   First Name
   <INPUT type="text" name="firstname">
</LABEL>
<LABEL>
   <INPUT type="text" name="lastname">
   Last Name
</LABEL>
</FORM>

The FIELDSET and LEGEND elements 

<!--
  #PCDATA is to solve the mixed content problem,
  per specification only whitespace is allowed there!
 -->
<!ELEMENT FIELDSET - - (#PCDATA,LEGEND,%block)>
<!ATTLIST FIELDSET
  %attrs;                          -- %coreattrs, %i18n, %events --
  >

<!ELEMENT LEGEND - - (%inline;)+>
<!ENTITY % LAlign "(top|bottom|left|right)">

<!ATTLIST LEGEND            -- fieldset legend --
  %attrs;                          -- %coreattrs, %i18n, %events --
  align       %LAlign;   #IMPLIED  -- relative to fieldset --
  accesskey   CDATA      #IMPLIED  -- accessibility key character --
  >

Start tag: required, End tag: required

LEGEND Attribute definitions

align = top|bottom|left|right
This attribute specifies the position of the legend with respect to the fieldset. Possible values:
  • top: The legend is above the fieldset. This is the default value.
  • bottom: The legend is below the fieldset.
  • left: The legend is to the left of the fieldset.
  • right: The legend is to the right of the fieldset.

Attributes defined elsewhere

The FIELDSET element allows form designers to group thematically related controls together. 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 to people with disabilities.

The LEGEND element allows designers to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually. When rendered visually, setting the align attribute on the LEGEND element aligns it with respect to the FIELDSET.

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.

<FORM action="..." method="post">
<FIELDSET>
<LEGEND align="top">Personal Information</LEGEND>
Last Name: <INPUT name="personal_lastname" type="text" tabindex="1">
First Name: <INPUT name="personal_firstname" type="text" tabindex="2">
Address: <INPUT name="personal_address" type="text" tabindex="3">
...more personal information...
</FIELDSET>
<FIELDSET>
<LEGEND align="top">Medical History</LEGEND>
<INPUT name="history_illness" 
       type="checkbox" 
       value="Smallpox" tabindex="20"> Smallpox</INPUT>
<INPUT name="history_illness" 
       type="checkbox" 
       value="Mumps" tabindex="21"> Mumps</INPUT>
<INPUT name="history_illness" 
       type="checkbox" 
       value="Dizziness" tabindex="22"> Dizziness</INPUT>
<INPUT name="history_illness" 
       type="checkbox" 
       value="Sneezing" tabindex="23"> Sneezing</INPUT>
...more medical history...
</FIELDSET>
<FIELDSET>
<LEGEND align="top">Current Medication</LEGEND>
Are you currently taking any medication? 
<INPUT name="medication_now" 
       type="radio" 
       value="Yes" tabindex="35">Yes</INPUT>
<INPUT name="medication_now" 
       type="radio" 
       value="No" tabindex="35">No</INPUT>

If you are currently taking medication, please indicate
it in the space below:
<TEXTAREA name="current_medication" 
          rows="20" cols="50"
          tabindex="40">
</TEXTAREA>
</FIELDSET>
</FORM>

Note that in this example, we might improve the 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.

Giving focus to an element 

Active elements in HTML documents must receive focus from the user in order to perform their 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:

Tabbing navigation 

Attribute definitions

tabindex = integer
This attribute specifies the position of the current element in the tabbing order for the current document. This value may be a positive or negative integer.

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.

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

  1. Those elements that support the tabindex attribute and assign a postive value to it are navigated first. Navigation proceeds from the element with the lowest tabindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tabindex should be navigated in the order they appear in the document.
  2. Those elements that do not define the tabindex attribute or do not support it are navigated next. These elements are navigated in the order they appear in the document.
  3. Those elements that support the tabindex attribute and assign a negative value to it do not participate in the tabbing order.
  4. Elements that are disabled do not participate in the tabbing order.

The following elements support the tabindex attribute: A, AREA, OBJECT, INPUT, SELECT, TEXTAREA, and BUTTON.

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 document), and finally the link created by the A element.

<HTML>
<BODY>
...some text...
Click to go to the 
<A tabindex="10" href="http://www.w3.org/">W3C Website.</A>
...some more...
<BUTTON type="button" name="get-database"
           tabindex="1" onclick="get-database">
Click me to receive the current database.
</BUTTON>
...some more...
<FORM action="..." method="post">
<INPUT tabindex="1" type="text" name="field1">
<INPUT tabindex="2" type="text" name="field2">
<INPUT tabindex="3" type="submit" name="submit">
</FORM>
</BODY>
</HTML>

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

Access keys 

Attribute definitions

accesskey = cdata
This attribute assigns an access key to an element. An access key is a single character from the user agent's current character encoding. User agents should treat the value of this attribute as case-insensitive.

Pressing an access key assigned to an element gives focus to the element. The action that is executed when an element receives focus depends on the element. Links defined by A are generally followed by the user agent, activated radio buttons change values, text fields with focus allow user input, etc.

The following elements support the accesskey attribute: LABEL, A, CAPTION, and LEGEND.

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.

<FORM action="..." method="post">
<LABEL for="user" accesskey="U">
User Name
</LABEL>
<INPUT type="text" name="user">
</FORM>

In this example, we assign an access key to a link defined by the A element. Typing this access key takes the user to another document, in this case, a table of contents.

<A accesskey="C" 
      href="http://somplace.com/specification/contents.html">
    Table of Contents</A>

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

Disabled and read-only elements 

In contexts where user input is either undesirable or irrelevant, it is important to be able to disable an element 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 elements.

Disabled elements 

Attribute definitions

disabled
When set for a form control, this boolean attribute disables the control for user input.

When set, the disabled attribute has the following effects on an element:

The following elements support the disabled attribute: INPUT, TEXTAREA, SELECT, OPTION, OBJECT, LABEL, and BUTTON.

How disabled elements are rendered depends on the user agent. For example, some user agents "gray out" disabled menu items, button labels, etc.

In this example, the disabled INPUT element cannot receive user input nor will its value be submitted with the form.

<INPUT disabled name="fred" value="stone">

Note: The only way to modify dynamically the value of the disabled attribute is through a script.

Read-only elements 

Attribute definitions

readonly
When set for a form control, this boolean attribute prohibits changes to control.

The readonly attribute specifies whether the element may be modified by the user.

When set, the readonly attribute has the following effects on an element:

The following elements support the readonly attribute: INPUT, TEXT, PASSWORD, and TEXTAREA.

How read-only elements are rendered depends on the user agent.

Note: The only way to modify dynamically the value of the readonly attribute is through a script.

Form submission 

Which element values are submitted 

Not all elements have their values submitted with a form. Conforming user agents should not submit: