17. Forms

17.1 Introduction to forms

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. Usersgenerally "complete" a form by modifying its controls (entering text, selectingmenu items, etc.), before submitting the form to an agent for processing (e.g.,to a Web server, to a mail server, etc.)

 <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"> </P> </FORM>

17.2 Controls

Users interact with forms through named controls.

A control's "control name" is given by its name attribute. The scope of the name attribute for acontrol within a FORM element is the FORM element.

Each control has both an initial value and a current value, both of whichare character strings. Please consult the definition of each control forinformation about initial values and possible constraints on values imposed bythe control. In general, a control's "initialvalue" may be specified with the control element's value attribute. However, the initial value of a TEXTAREA element is given by its contents, and the initial value ofan OBJECT element in a form is determined by the objectimplementation (i.e., it lies outside the scope of this specification).

The control's "current value" is first set to theinitial value. Thereafter, the control's current value may be modified throughuser interaction and scripts.

A control's initial value does not change. Thus, whena form is reset, each control's current value is reset to its initial value. Ifa control does not have an initial value, the effect of a form reset on thatcontrol is undefined.

When a form is submitted for processing, some controls have their namepaired with their current value and these pairs are submitted with the form. Those controls for which name/value pairs aresubmitted are called successfulcontrols.

17.2.1 Controltypes

HTML defines the following control types:

buttons

Authors may create three types of buttons:

• submit buttons: When activated, a submit button submits a form. A form may contain more than one submitbutton.
• resetbuttons: When activated, a reset button resets all controls to theirinitial values.
• pushbuttons: Push buttons have no default behavior. Each push button mayhave client-side scripts associated with theelement's event attributes. When an eventoccurs (e.g., the user presses the button, releases it, etc.), the associatedscript is triggered.

  Authors should specify the scripting language of a push button scriptthrough a default script declaration(with the META element).

Authors create buttons with the BUTTON element or the INPUTelement. Please consult the definitions of these elements for details aboutspecifying different button types.

Note. Authors should note that the BUTTONelement offers richer rendering capabilities than the INPUTelement.

checkboxes

Checkboxes (and radio buttons) are on/off switches that may be toggled bythe user. A switch is "on" when the control element's checkedattribute is set. When a form is submitted, only "on" checkbox controls canbecome successful.

Several checkboxes in a form may share the same control name. Thus, for example, checkboxes allow users to select severalvalues for the same property. The INPUT element is used to create acheckbox control.

radiobuttons

Radio buttons are like checkboxes except that when several share the samecontrol name, they are mutually exclusive: when oneis switched "on", all others with the same name are switched "off". The INPUT element is used to create a radio button control.

If no radio button in a set sharing the same control name is initially"on", user agent behavior for choosing which control is initially "on" isundefined. Note. Since existing implementations handle thiscase differently, the current specification differs from RFC 1866 ([RFC1866] section 8.1.2.4), which states:

At all times, exactly one of the radio buttons in a set is checked.If none of the <INPUT> elements of a set of radio buttons specifies`CHECKED', then the user agent must check the first radio button of the setinitially.

Since user agent behavior differs, authors should ensure that in each set ofradio buttons that one is initially "on".

menus

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

text input

Authors may create two types of controls that allow users to input text.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 currentvalue.

file select

This control type allows the user to select files so that their contentsmay be submitted with a form. The INPUT element is used to create a fileselect control.

hidden controls

Authors may create controls that are not rendered but whose values aresubmitted with a form. Authors generally use this control type to storeinformation between client/server exchanges that would otherwise be lost due tothe stateless nature of HTTP (see [RFC2616]). The INPUTelement is used to create a hidden control.

object controls

Authors may insert generic objects in forms such that associated values aresubmitted along with other controls. Authors create object controls with the OBJECT element.

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

17.3 The FORM element

<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- interactive form --><!ATTLIST FORM  %attrs;  -- %coreattrs, %i18n, %events --  action  %URI;  #REQUIRED -- server-side form handler --  method  (GET|POST) GET   -- HTTP method used to submit the form--  enctype %ContentType;  "application/x-www-form-urlencoded"  accept  %ContentTypes; #IMPLIED  -- list of MIME types for file upload --  name CDATA  #IMPLIED  -- name of form for scripting --  onsubmit %Script;   #IMPLIED  -- the form was submitted --  onreset %Script;   #IMPLIED  -- the form was reset --  accept-charset %Charsets;  #IMPLIED  -- list of supported charsets --  >

Start tag: required, End tag: required

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

• The layout of the form (given by the contents of the element).
• The program that will handle the completed and submitted form (the actionattribute). The receiving program must be able to parse name/value pairs inorder to make use of them.
• The method by which user data will be sent to the server (the methodattribute).
• A character encoding that must be accepted by the server in order to handlethis form (the accept-charset attribute). User agents may advise theuser of the value of the accept-charset attribute and/orrestrict the user's ability to enter unrecognized characters.

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

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

Please consult the section on form submissionfor information about how user agents must prepare form data for servers andhow user agents should handle expected responses.

17.4 The INPUT element

<!ENTITY % InputType  "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE | BUTTON)"   ><!-- attribute name required for all but submit and reset --><!ELEMENT INPUT - O EMPTY  -- form control --><!ATTLIST INPUT  %attrs;  -- %coreattrs, %i18n, %events --  type %InputType; TEXT  -- what kind of widget is needed --  name CDATA  #IMPLIED  -- submit as part of form --  value   CDATA  #IMPLIED  -- Specify for radio buttons and checkboxes --  checked (checked)  #IMPLIED  -- for radio buttons and check boxes --  disabled (disabled) #IMPLIED  -- 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 %URI;  #IMPLIED  -- for fields with images --  alt CDATA  #IMPLIED  -- short description --  usemap  %URI;  #IMPLIED  -- use client-side image map --  ismap   (ismap) #IMPLIED  -- use server-side image map --  tabindex NUMBER #IMPLIED  -- position in tabbing order --  accesskey   %Character; #IMPLIED  -- accessibility key character --  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  %ContentTypes; #IMPLIED  -- list of MIME types for file upload --  >

Start tag: required, End tag: forbidden

17.4.1 Control typescreated with INPUT

The control type defined by the INPUTelement depends on the value of the type attribute:

text

Creates asingle-line textinput control.

password

Like "text", but the input text isrendered 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. Notethat the current value is the text entered by the user, not the text rendered by the user agent.

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

checkbox

Creates a checkbox.

radio

Creates a radio button.

submit

Creates a submit button.

image

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

When a pointing device is used to click on theimage, the form is submitted and the click coordinates passed to theserver. 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 submitteddata includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-valueare 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, authorsshould consider alternate approaches:

• Use multiple submit buttons (each with its own image) in place of a singlegraphical submit button. Authors may use style sheets to control thepositioning of these buttons.
• Use a client-side imagemap together with scripting.

reset

Creates a reset button.

button

Creates a push button. User agents should usethe value of the value attribute as the button'slabel.

hidden

Creates a hidden control.

file

Creates a file select control. User agents mayuse the value of the value attribute as the initial file name.

17.4.2 Examples of forms containing INPUTcontrols

 <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"> </P> </FORM>

<HEAD><META http-equiv="Content-Script-Type" content="text/javascript"></HEAD><BODY> <FORM action="..." method="post"> <P> <INPUT type="button" value="Click Me" onclick="verify()"> </FORM></BODY>

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

17.5 The BUTTON element

<!ELEMENT BUTTON - - (%flow;)* -(A|%formctrl;|FORM|FIELDSET) -- push button --><!ATTLIST BUTTON  %attrs;  -- %coreattrs, %i18n, %events --  name CDATA  #IMPLIED  value   CDATA  #IMPLIED  -- sent to server when submitted --  type (button|submit|reset) submit -- for use as form button --  disabled (disabled) #IMPLIED  -- unavailable in this context --  tabindex NUMBER #IMPLIED  -- position in tabbing order --  accesskey   %Character; #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

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

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

 <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> </P> </FORM>

Recall that authors must provide alternate text for an IMG element.

It is illegal toassociate an image map with an IMG that appears as the contents of aBUTTON element.

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

17.6 The SELECT, OPTGROUP, and OPTION elements

<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --><!ATTLIST SELECT  %attrs;  -- %coreattrs, %i18n, %events --  name CDATA  #IMPLIED  -- field name --  size NUMBER #IMPLIED  -- rows visible --  multiple (multiple) #IMPLIED  -- default is single selection --  disabled (disabled) #IMPLIED  -- 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 --  onchange %Script;   #IMPLIED  -- the element value was changed --  >

Start tag: required, End tag: required

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

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

17.6.1 Pre-selectedoptions

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

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

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

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

• If one OPTION element has the selected attribute set, it should bepre-selected.
• If the SELECT element has the multiple attribute set and more thanone OPTION element has the selected attribute set, they should allbe 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 themultiple attribute set. User agents may vary in how they handle thiserror, but should not pre-select more than one choice.

<!ELEMENT OPTGROUP - - (OPTION)+ -- option group --><!ATTLIST OPTGROUP  %attrs;  -- %coreattrs, %i18n, %events --  disabled (disabled) #IMPLIED  -- unavailable in this context --  label   %Text; #REQUIRED -- for use in hierarchical menus --  >

Start tag: required, End tag: required

<!ELEMENT OPTION - O (#PCDATA) -- selectable choice --><!ATTLIST OPTION  %attrs;  -- %coreattrs, %i18n, %events --  selected (selected) #IMPLIED  disabled (disabled) #IMPLIED  -- unavailable in this context --  label   %Text; #IMPLIED  -- for use in hierarchical menus --  value   CDATA  #IMPLIED  -- defaults to element content --  >

Start tag: required, End tag: optional

When rendering a menu choice, user agents should usethe value of the label attribute of the OPTIONelement as the choice. If this attribute is not specified, user agents shoulduse the contents of the OPTION element.

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

<FORM action="http://somesite.com/prog/component-select" method="post">   <P>   <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">   </P></FORM>

<FORM action="http://somesite.com/prog/someprog" method="post"> <P> <SELECT name="ComOS"> <OPTION selected label="none" value="none">None</OPTION> <OPTGROUP label="PortMaster 3">   <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1</OPTION>   <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7</OPTION>   <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="PortMaster 2">   <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7</OPTION>   <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5</OPTION> </OPTGROUP> <OPTGROUP label="IRX">   <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R</OPTION>   <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R</OPTION> </OPTGROUP> </SELECT></FORM>

  None  PortMaster 3  3.7.1  3.7  3.5  PortMaster 2  3.7  3.5  IRX  3.7R  3.5R

17.7 The TEXTAREA element

<!ELEMENT TEXTAREA - - (#PCDATA)   -- multi-line text field --><!ATTLIST TEXTAREA  %attrs;  -- %coreattrs, %i18n, %events --  name CDATA  #IMPLIED  rows NUMBER #REQUIRED  cols NUMBER #REQUIRED  disabled (disabled) #IMPLIED  -- unavailable in this context --  readonly (readonly) #IMPLIED  tabindex NUMBER #IMPLIED  -- position in tabbing order --  accesskey   %Character; #IMPLIED  -- accessibility key character --  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

The TEXTAREA element creates a multi-line text input control. User agentsshould use the contents of this element as the initialvalue of the control and should render this text initially.

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

17.8 The ISINDEX element

ISINDEX is deprecated. This element creates a single-line text input control. Authors should use the INPUTelement to create text input controls.

See the Transitional DTD for theformal definition.

The ISINDEX element creates a single-line textinput control that allows any number of characters. User agents may use thevalue of the prompt attribute as a title for the prompt.

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

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

17.9 Labels

Some form controls automatically have labels associated with them (pressbuttons) while most do not (text fields, checkboxes and radio buttons, andmenus).

For those controls that have implicit labels, user agents should use thevalue of the value attribute as the labelstring.

The LABEL element is used to specify labels for controls that do nothave implicit labels,

17.9.1 The LABEL element

<!ELEMENT LABEL - - (%inline;)* -(LABEL) -- form field label text --><!ATTLIST LABEL  %attrs;  -- %coreattrs, %i18n, %events --  for IDREF  #IMPLIED  -- matches field ID value --  accesskey   %Character; #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

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 controlexplicitly: 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 multiplereferences via the for attribute.

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

 <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"> </P> </FORM>

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

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

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

Labels may be rendered by user agents in a number of ways (e.g., visually,read by speech synthesizers, etc.)

17.10 Adding structure toforms: the FIELDSETand LEGEND elements

<!--  #PCDATA is to solve the mixed content problem,  per specification only whitespace is allowed there! --><!ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*) -- form control group --><!ATTLIST FIELDSET  %attrs;  -- %coreattrs, %i18n, %events --  ><!ELEMENT LEGEND - - (%inline;)*   -- fieldset legend --><!ATTLIST LEGEND  %attrs;  -- %coreattrs, %i18n, %events --  accesskey   %Character; #IMPLIED  -- accessibility key character --  >

Start tag: required, End tag: required

The FIELDSET element allows authors to group thematicallyrelated controls and labels. Grouping controls makes it easier for users tounderstand their purpose while simultaneously facilitating tabbing navigationfor 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.

<FORM action="..." method="post"> <P> <FIELDSET>  <LEGEND>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>Medical History</LEGEND>  <INPUT name="history_illness"  type="checkbox"  value="Smallpox" tabindex="20"> Smallpox  <INPUT name="history_illness"  type="checkbox"  value="Mumps" tabindex="21"> Mumps  <INPUT name="history_illness"  type="checkbox"  value="Dizziness" tabindex="22"> Dizziness  <INPUT name="history_illness"  type="checkbox"  value="Sneezing" tabindex="23"> Sneezing  ...more medical history... </FIELDSET> <FIELDSET>  <LEGEND>Current Medication</LEGEND>  Are you currently taking any medication?   <INPUT name="medication_now"  type="radio"  value="Yes" tabindex="35">Yes  <INPUT name="medication_now"  type="radio"  value="No" tabindex="35">No  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>

17.11 Giving focus to anelement

In an HTML document, an element must receive focus from the userin order to become active and perform its tasks. For example, users mustactivate a link specified by the A element in order to follow thespecified link. Similarly, users must give a TEXTAREA focus in order to entertext 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'sauthor may define a tabbing order that specifies the order in whichelements will receive focus if the user navigates the document with thekeyboard (see tabbing navigation). Onceselected, an element may be activated by some other key sequence.
• Select an element through an access key(sometimes called "keyboard shortcut" or "keyboard accelerator").

17.11.1 Tabbing navigation

The tabbing orderdefines the order in which elements will receive focus when navigated by theuser via the keyboard. The tabbing order may include elements nested withinother elements.

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

1. Those elements that support the tabindex attribute and assign apositive value to it are navigated first. Navigation proceeds from the elementwith the lowest tabindex value to the element with the highest value. Valuesneed not be sequential nor must they begin with any particular value. Elementsthat have identical tabindex values should be navigated in the order theyappear in the character stream.
2. Those elements that do not support the tabindex attribute or support itand assign it a value of "0" are navigated next. These elements are navigatedin the order they appear in the character stream.
3. Elements that are disabled do not participate inthe tabbing order.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"   "http://www.w3.org/TR/html4/strict.dtd"><HTML><HEAD><TITLE>A document with FORM</TITLE></HEAD><BODY>...some text...<P>Go to the <A tabindex="10" href="http://www.w3.org/">W3C Web site.</A>...some more...<BUTTON type="button" name="get-database"   tabindex="1" onclick="get-database">Get the current database.</BUTTON>...some more...<FORM action="..." method="post"><P><INPUT tabindex="1" type="text" name="field1"><INPUT tabindex="2" type="text" name="field2"><INPUT tabindex="3" type="submit" name="submit"></P></FORM></BODY></HTML>

17.11.2 Access keys

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

The following elements support the accesskey attribute: A,AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.

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

<P><A accesskey="C"   rel="contents"  href="http://someplace.com/specification/contents.html"> Daftar Isi</A>

The invocation of access keys depends on the underlying system. Forinstance, 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 pressthe "cmd" key in addition to the access key.

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

17.12 Disabled andread-only controls

In contexts where user input is either undesirable or irrelevant, it isimportant 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 somerequired data. Similarly, an author may want to include a piece of read-onlytext that must be submitted as a value along with the form. The followingsections describe disabled and read-only controls.

17.12.1 Disabledcontrols

When set, the disabled attribute has the following effects on anelement:

• Disabled controls do not receive focus.
• Disabled controls are skipped in tabbingnavigation.
• Disabled controls cannot be successful.

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

This attribute is inherited but local declarations override the inheritedvalue.

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

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

17.12.2 Read-onlycontrols

The readonly attribute specifies whether the control may be modified bythe user.

When set, the readonly attribute has the following effects on anelement:

• Read-only elements receive focus but cannot bemodified by the user.
• Read-only elements are included in tabbingnavigation.
• Read-only elements may be successful.

The following elements support the readonly attribute: INPUT andTEXTAREA.

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

17.13 Form submission

The following sections explain how user agents submit form data to formprocessing agents.

17.13.1 Form submissionmethod

The method attribute of the FORM element specifies the HTTP methodused to send the form to the processing agent. This attribute may take twovalues:

• get: With the HTTP "get" method, the form data set is appended to the URI specified by the actionattribute (with a question-mark ("?") as separator) and this new URI is sent tothe processing agent.
• post: With the HTTP "post" method, the form data set is included in the body of the form and sentto the processing agent.

The "get" method should be used when the form is idempotent (i.e., causes noside-effects). Many database searches have no visible side-effects and makeideal applications for the "get" method.

If the service associated with the processing of a form causes side effects(for example, if the form modifies a database or subscription to a service),the "post" method should be used.

17.13.2 Successful controls

A successful control is "valid" for submission. Every successfulcontrol has its control name paired with its current value as part of the submitted form data set. A successful control must be defined withina FORM element and must have a controlname.

However:

• Controls that are disabled cannot be successful.
• If a form contains more than one submit button, onlythe activated submit button is successful.
• All "on" checkboxes may be successful.
• For radio buttons that share the same value of the name attribute, only the "on" radio button may be successful.
• For menus, the control nameis provided by a SELECT element and values are provided by OPTIONelements. Only selected options may be successful. When no options areselected, the control is not successful and neither the name nor any values aresubmitted to the server when the form is submitted.
• The current valueof a file select is a list of one or more filenames. Upon submission of the form, the contents of each file aresubmitted with the rest of the form data. The file contents are packagedaccording to the form's content type.
• The current value of an object control is determined by the object'simplementation.

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

Furthermore, user agents should not consider the following controlssuccessful:

• Reset buttons.
• OBJECT elements whose declare attribute has been set.

Hidden controls andcontrols that are not rendered because of style sheet settings may still be successful. For example:

<FORM action="..." method="post"><P><INPUT type="password" style="display:none" name="invisible-password"  value="mypassword"></FORM>

17.13.3 Processing formdata

When the user submits a form (e.g., by activating a submit button), the user agent processes it asfollows.

Step one: Identify the successfulcontrols 

Step two: Build a form data set 

Aform data set is a sequence of control-name/current-value pairs constructedfrom successful controls

Step three: Encode the form dataset 

The form data set is then encoded according to the content type specified by the enctypeattribute of the FORM element.

Step four: Submit the encoded form data set 

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

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

• If the method is "get" and the action is an HTTP URI, the user agenttakes the value of action, appends a `?' to it, then appends theform data set, encoded using the"application/x-www-form-urlencoded" contenttype. 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 agentconducts an HTTP "post" transaction using the value of the actionattribute and a message created according to the content type specified by the enctype attribute.

For any other value of action or method, behavior is unspecified.

User agents should render the response from the HTTP "get" and "post"transactions.

17.13.4 Form content types

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

Please also consult the section on escaping ampersands in URIattribute values.

application/x-www-form-urlencoded  

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

1. 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 ASCIIcode of the character. Line breaks are represented as "CR LF" pairs (i.e.,`%0D%0A').
2. The control names/values are listed in the order they appear in thedocument. The name is separated from the value by `=' andname/value pairs are separated from each other by `&'.

multipart/form-data  

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

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

A "multipart/form-data" message contains a series of parts, eachrepresenting a successful control. The partsare sent to the processing agent in the same order the corresponding controlsappear in the document stream. Part boundaries should not occur in any of thedata; 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:

1. a "Content-Disposition" header whose value is "form-data".
2. a name attribute specifying the control name ofthe corresponding control. Control names originally encoded in non-ASCII character sets may be encoded using the methodoutlined in [RFC2045].

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

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

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

Each part may be encoded and the "Content-Transfer-Encoding" header suppliedif 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 shouldbe identified by the appropriate content type (e.g., "application/octet-stream"). If multiple files are tobe 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, ina 'Content-Disposition: file' header of the subpart. If the file name of theclient's operating system is not in US-ASCII, the file name might beapproximated or encoded using the method of [RFC2045]. This isconvenient for those cases where, for example, the uploaded files might containreferences to each other (e.g., a TeX file and its ".sty" auxiliary styledescription).

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

 <FORM action="http://server.com/cgi/handle"   enctype="multipart/form-data"   method="post">   <P>   What is your name? <INPUT type="text" name="submit-name"><BR>   What files are you sending? <INPUT type="file" name="files"><BR>   <INPUT type="submit" value="Send"> <INPUT type="reset"> </FORM>

If the user enters "Larry" in the text input, and selects the text file"file1.txt", the user agent might send back the following data:

   Content-Type: multipart/form-data; boundary=AaB03x   --AaB03x   Content-Disposition: form-data; name="submit-name"   Larry   --AaB03x   Content-Disposition: form-data; name="files"; filename="file1.txt"   Content-Type: text/plain   ... contents of file1.txt ...   --AaB03x--

If the user selected a second (image) file "file2.gif", the user agent mightconstruct the parts as follows:

   Content-Type: multipart/form-data; boundary=AaB03x   --AaB03x   Content-Disposition: form-data; name="submit-name"   Larry   --AaB03x   Content-Disposition: form-data; name="files"   Content-Type: multipart/mixed; boundary=BbC04y   --BbC04y   Content-Disposition: file; filename="file1.txt"   Content-Type: text/plain   ... contents of file1.txt ...   --BbC04y   Content-Disposition: file; filename="file2.gif"   Content-Type: image/gif   Content-Transfer-Encoding: binary   ...contents of file2.gif...   --BbC04y--   --AaB03x--