Movatterモバイル変換
[0]ホーム
17.1 Introduction to forms
An HTML form is a section of a document containing normal content, markup,special elements calledcontrols(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.)
Here's a simple form that includes labels, radio buttons, and push buttons(reset the form or submit it):
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="firstname">First name: </LABEL> <INPUT type="text"><BR> <LABEL for="lastname">Last name: </LABEL> <INPUT type="text"><BR> <LABEL for="email">email: </LABEL> <INPUT type="text"><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>
Note. This specification includes more detailedinformation about forms in the subsections onform display issues.
Users interact with forms through namedcontrols.
A control's"control name" is given by itsname attribute. The scope of thename attribute for acontrol within aFORM element is theFORM 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'svalue attribute. However, the initial value of aTEXTAREA element is given by its contents, and the initial value ofanOBJECT 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 andscripts.
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 aresubmitted with the form. Those controls for which name/value pairs aresubmitted are calledsuccessfulcontrols.
HTML defines the following control types:
- buttons
- Authors may create three types of buttons:
Authors create buttons with theBUTTON element or theINPUTelement. Please consult the definitions of these elements for details aboutspecifying different button types.
Note. Authors should note that theBUTTONelement offers richer rendering capabilities than theINPUTelement.
- checkboxes
- Checkboxes (and radio buttons) are on/off switches that may be toggled bythe user. A switch is "on" when the control element'scheckedattribute is set. When a form is submitted, only "on" checkbox controls canbecomesuccessful.
Several checkboxes in a form may share the samecontrol name. Thus, for example, checkboxes allow users to select severalvalues for the same property. TheINPUT 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". TheINPUT 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. TheSELECTelement creates a menu, in combination with theOPTGROUP andOPTION elements.
- text input
- Authors may create two types of controls that allow users to input text.TheINPUT element creates a single-line input control and theTEXTAREA element creates a multi-line input control. In both cases,the input text becomes the control'scurrentvalue.
- file select
- This control type allows the user to select files so that their contentsmay be submitted with a form. TheINPUT 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]). TheINPUTelement 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 theOBJECT element.
The elements used to create controls generally appear inside aFORMelement, but may also appear outside of aFORM element declaration when they areused to build user interfaces. This is discussed in the section onintrinsic events. Note that controls outside a formcannot besuccessful controls.
Start tag:required, End tag:required
Attribute definitions
- action =uri[CT]
- This attribute specifies a form processing agent. User agent behavior for avalue other than an HTTP URI is undefined.
- method =get|post[CI]
- This attribute specifies which HTTP method will be used to submit theform data set. Possible (case-insensitive) values are"get" (the default) and "post". See the section onform submission for usage information.
- enctype =content-type[CI]
- This attribute specifies thecontent typeused to submit the form to the server (when the value ofmethodis "post"). The default value for this attribute is"application/x-www-form-urlencoded". The value"multipart/form-data" should be used in combination with theINPUT element,type="file".
- accept-charset=charset list[CI]
- This attribute specifies the list ofcharacter encodings for inputdata that is accepted by the server processing this form. The value is a space-and/or comma-delimited list ofcharsetvalues. The client must interpret this list as an exclusive-or list, i.e., theserver is able to accept any single character encoding per entity received.
The default value for this attribute is the reserved string "UNKNOWN". Useragents may interpret this value as the character encoding that was used totransmit the document containing thisFORM element.
- accept =content-type-list[CI]
- This attribute specifies a comma-separated list of content types that aserver processing this form will handle correctly. User agents may use thisinformation to filter out non-conforming files when prompting a user to selectfiles to be sent to the server (cf. theINPUT element whentype="file").
- name =cdata[CI]
- This attribute names the element so that it may be referred to from stylesheets or scripts.Note. This attribute has been included forbackwards compatibility. Applications should use theid attribute to identify elements.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- style (inlinestyle information)
- title (elementtitle)
- target (targetframe information)
- onsubmit,onreset,onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
TheFORM element acts as a container forcontrols. It specifies:
- The layout of the form (given by the contents of the element).
- The program that will handle the completed and submitted form (theactionattribute). 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 (themethodattribute).
- A character encoding that must be accepted by the server in order to handlethis form (theaccept-charset attribute). User agents may advise theuser of the value of theaccept-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.
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.
<FORM action="http://somesite.com/prog/adduser" method="post">...form contents... </FORM>
Please consult the section onform submissionfor information about how user agents must prepare form data for servers andhow user agents should handle expected responses.
Note. Further discussion on the behavior of serversthat receive form data is beyond the scope of this specification.
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE | BUTTON)" ><!-- attribute name required for all but submit and reset --><!ELEMENTINPUT - O EMPTY -- form control --><!ATTLIST INPUT%attrs; --%coreattrs,%i18n,%events --type%InputType; TEXT -- what kind of widget is needed --nameCDATA #IMPLIED -- submit as part of form --valueCDATA #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 --sizeCDATA #IMPLIED -- specific to each type of field --maxlengthNUMBER #IMPLIED -- max chars for text fields --src%URI; #IMPLIED -- for fields with images --altCDATA #IMPLIED -- short description --usemap%URI; #IMPLIED -- use client-side image map --ismap (ismap) #IMPLIED -- use server-side image map --tabindexNUMBER #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
Attribute definitions
- type =text|password|checkbox|radio|submit|reset|file|hidden|image|button[CI]
- This attribute specifies thetype ofcontrol to create. The default value for this attribute is "text".
- name =cdata[CI]
- This attribute assigns thecontrol name.
- value =cdata[CA]
- This attribute specifies theinitial value ofthe control. It is optional except when thetype attribute has the value "radio" or "checkbox".
- size =cdata[CN]
- This attribute tells the user agent the initial width of the control. Thewidth is given inpixels except whentype attribute has the value "text" or "password". In that case, itsvalue refers to the (integer) number of characters.
- maxlength =number[CN]
- When thetype attribute has the value "text" or "password",this attribute specifies the maximum number of characters the user may enter.This number may exceed the specifiedsize, in which case theuser agent should offer a scrolling mechanism. The default value for thisattribute is an unlimited number.
- checked[CI]
- When thetype attribute has the value "radio" or "checkbox",this boolean attribute specifies that the button is on. User agents must ignorethis attribute for other control types.
- src =uri[CT]
- When thetype attribute has the value "image", this attributespecifies the location of the image to be used to decorate the graphical submitbutton.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- alt (alternate text)
- align (alignment)
- accept (legal content types for aserver)
- readonly (read-only input controls)
- disabled (disabled input controls)
- tabindex (tabbing navigation)
- accesskey (accesskeys)
- usemap (client-side image maps)
- ismap (server-side image maps)
- onfocus,onblur,onselect,onchange,onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
Thecontrol type defined by theINPUTelement depends on the value of thetype attribute:
- text
- Creates asingle-linetextinput 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 thecurrent value is the textentered 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 acheckbox.
- radio
- Creates aradio button.
- submit
- Creates asubmit button.
- image
- Creates a graphicalsubmit button. The valueof thesrc attribute specifies the URI of the image that will decorate thebutton. For accessibility reasons, authors should providealternate text for the image viathealt 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 inpixels from the left of the image, and the y value inpixels from the top of the image. The submitteddata includesname.x=x-value andname.y=y-value where"name" is the value of thename attribute, andx-value andy-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 aclient-side imagemap together with scripting.
- reset
- Creates areset button.
- button
- Creates apush button. User agents should usethe value of thevalue attribute as the button'slabel.
- hidden
- Creates ahidden control.
- file
- Creates afile select control. User agents mayuse the value of thevalue attribute as the initial file name.
17.4.2 Examples of forms containing INPUTcontrols
The following sample HTML fragment defines a simple form that allows theuser to enter a first name, last name, email address, and gender. When thesubmit button is activated, the form will be sent to the program specified bytheaction 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"> </P> </FORM>
This form might be rendered as follows:
In the section on theLABEL element, we discuss marking up labels such as"First name".
In this next example, the JavaScript function nameverify istriggered when the "onclick" event occurs:
<HEAD><META http-equiv="Content-Script-Type" content="text/javascript"></HEAD><BODY> <FORM action="..." method="post"> <P> <INPUT type="button" value="Click Me"> </FORM></BODY>
Please consult the section onintrinsicevents for more information about scripting and events.
The following example shows how the contents of a user-specified file may besubmitted with a form. The user is prompted for his or her name and a list offile names whose contents should be submitted with the form. By specifying theenctype value of "multipart/form-data", each file's contents will bepackaged for submission in a separate section of a multipart document.
<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>
Start tag:required, End tag:required
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- disabled (disabled input controls)
- accesskey (accesskeys)
- tabindex (tabbing navigation)
- onfocus,onblur,onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
Buttons created with theBUTTON element function just like buttonscreated with theINPUT element, but they offer richer renderingpossibilities: theBUTTON element may have content. For example, aBUTTONelement that contains an image functions like and may resemble anINPUTelement whosetype is set to "image", but theBUTTONelement type allows content.
Visual user agents may renderBUTTON buttons with relief and anup/down motion when clicked, while they may renderINPUTbuttons as "flat" images.
The following example expands a previous example, but createssubmit andreset buttons withBUTTON instead ofINPUT. The buttons contain images by way of theIMG 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> </P> </FORM>
Recall that authors must providealternate text for anIMG element.
It is illegal toassociate an image map with anIMG that appears as the contents of aBUTTON element.
ILLEGAL EXAMPLE:
The following is not legal HTML.
<BUTTON><IMG src="foo.gif" usemap="..."></BUTTON>
Start tag:required, End tag:required
SELECT Attribute definitions
- name =cdata[CI]
- This attribute assigns thecontrol name.
- size =number[CN]
- If aSELECT element is presented as a scrolled list box, this attributespecifies the number of rows in the list that should be visible at the sametime. Visual user agents are not required to present aSELECTelement as a list box; they may use any other mechanism, such as a drop-downmenu.
- multiple[CI]
- If set, this boolean attribute allows multiple selections. If not set, theSELECT element only permits single selections.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- disabled (disabled input controls)
- tabindex (tabbing navigation)
- onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
TheSELECT element creates amenu. Each choiceoffered by the menu is represented by anOPTION element. ASELECTelement must contain at least oneOPTION element.
TheOPTGROUP 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, allOPTGROUP elements must be specified directly within aSELECTelement (i.e., groups may not be nested).
Zero or more choices may be pre-selected for the user. User agents shoulddetermine which choices are pre-selected as follows:
Start tag:required, End tag:required
OPTGROUP Attribute definitions
- label =text[CS]
- This attribute specifies the label for the option group.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- disabled (disabled input controls)
- onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
Note. Implementors are advised that future versions ofHTML may extend the grouping mechanism to allow for nested groups (i.e.,OPTGROUP elements may nest). This will allow authors to represent aricher hierarchy of choices.
Start tag:required, End tag:optional
OPTION Attribute definitions
- selected[CI]
- When set, this boolean attribute specifies that this option ispre-selected.
- value =cdata[CS]
- This attribute specifies theinitial value ofthe control. If this attribute is not set, theinitialvalue is set to the contents of theOPTION element.
- label =text[CS]
- This attribute allows authors to specify a shorter label for an option thanthe content of theOPTION element. When specified, user agents should use thevalue of this attribute rather than the content of theOPTIONelement as the option label.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- disabled (disabled input controls)
- onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
When rendering a menu choice, user agents should usethe value of thelabel attribute of theOPTIONelement as the choice. If this attribute is not specified, user agents shoulduse the contents of theOPTION element.
Thelabel attribute of theOPTGROUP element specifies the label for a group of choices.
In this example, we create a menu that allows the user to select which ofseven software components to install. The first and second components arepre-selected but may be deselected by the user. The remaining components arenot pre-selected. Thesize attribute states that the menushould 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.
TheSELECT is followed by submit and reset buttons.
<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>
Only selected options will besuccessful(using thecontrol name "component-select"). Whenno options are selected, the control is not successful and neither the name norany values are submitted to the server when the form is submitted. Note thatwhere thevalue attribute is set, it determines the control'sinitial value, otherwise it's the element'scontents.
In this example we use theOPTGROUP element to group choices. Thefollowing markup:
<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>
represents the following grouping:
None PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 IRX 3.7R 3.5R
Visual user agents may allow users to selectfrom option groups through a hierarchical menu or some other mechanism thatreflects the structure of choices.
A graphical user agent might render this as:
This image shows aSELECT element rendered as cascading menus. The toplabel 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 newvalue (PortMaster 2, 3.7). Note that each cascading menu displays the label ofanOPTGROUP orOPTION element.
Start tag:required, End tag:required
Attribute definitions
- name =cdata[CI]
- This attribute assigns thecontrol name.
- rows =number[CN]
- This attribute specifies the number of visible text lines. Users should beable to enter more lines than this, so user agents should provide some means toscroll through the contents of the control when the contents extend beyond thevisible area.
- cols =number[CN]
- This attribute specifies the visible width in average character widths.Users should be able to enter longer lines than this, so user agents shouldprovide some means to scroll through the contents of the control when thecontents extend beyond the visible area. User agents may wrap visible textlines to keep long lines visible without the need for scrolling.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- readonly (read-only input controls)
- disabled (disabled input controls)
- tabindex (tabbing navigation)
- onfocus,onblur,onselect,onchange,onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
TheTEXTAREA element creates amulti-linetext input control. User agentsshould use the contents of this element as theinitialvalue of the control and should render this text initially.
This example creates aTEXTAREA control that is 20 rows by 80 columnsand contains two lines of text initially. TheTEXTAREA is followed by submit and reset buttons.
<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>
Setting thereadonly attribute allows authors to display unmodifiabletext in aTEXTAREA. This differs from using standard marked-up text ina document because the value ofTEXTAREA is submitted with theform.
ISINDEX isdeprecated. This element creates a single-linetext input control. Authors should use theINPUTelement to createtext input controls.
See theTransitional DTD for theformal definition.
Attributes defined elsewhere
TheISINDEX element creates a single-linetextinput control that allows any number of characters. User agents may use thevalue of theprompt attribute as a title for the prompt.
DEPRECATED EXAMPLE:
The followingISINDEX declaration:
<ISINDEX prompt="Enter your search phrase: ">
could be rewritten withINPUT as follows:
<FORM action="..." method="post"><P>Enter your search phrase: <INPUT type="text"></P></FORM>
Semantics ofISINDEX.Currently, the semantics forISINDEX are only well-defined when the base URIfor the enclosing document is an HTTP URI. In practice, the input string isrestricted to Latin-1 as there is no mechanism for the URI to specify adifferent character set.
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 thevalue attribute as the labelstring.
TheLABEL element is used to specify labels for controls that do nothave implicit labels,
Start tag:required, End tag:required
Attribute definitions
- for =idref[CS]
- This attribute explicitly associates the label being defined with anothercontrol. When present, the value of this attribute must be the same as thevalue of theid attribute of some other control in the samedocument. When absent, the label being defined is associated with the element'scontents.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- accesskey (accesskeys)
- onfocus,onblur,onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
TheLABEL element may be used to attach information to controls. EachLABEL element is associated with exactly one form control.
Thefor attribute associates a label with another controlexplicitly: the value of thefor attribute must be the same as the value of theid attribute of the associated control element. More than oneLABEL may be associated with the same control by creating multiplereferences via thefor attribute.
This example creates a table that is used to align twotext input controls and their associated labels. Each labelis associated explicitly with onetext input:
<FORM action="..." method="post"><TABLE> <TR> <TD><LABEL for="fname">First Name</LABEL> <TD><INPUT type="text" name="firstname"> <TR> <TD><LABEL for="lname">Last Name</LABEL> <TD><INPUT type="text" name="lastname"></TABLE></FORM>
This example extends a previous example form to includeLABELelements.
<FORM action="http://somesite.com/prog/adduser" method="post"> <P> <LABEL for="firstname">First name: </LABEL> <INPUT type="text"><BR> <LABEL for="lastname">Last name: </LABEL> <INPUT type="text"><BR> <LABEL for="email">email: </LABEL> <INPUT type="text"><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 theLABELelement. In this case, theLABEL may only contain one control element. The labelitself may be positioned before or after the associated control.
In this example, we implicitly associate two labels with twotext input controls:
<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>
Note that this technique cannot be used when a table is being used forlayout, with the label in one cell and its associated control in anothercell.
When aLABEL element receivesfocus, it passes the focus on to its associated control. See thesection below onaccess keys for examples.
Labels may be rendered by user agents in a number of ways (e.g., visually,read by speech synthesizers, etc.)
Start tag:required, End tag:required
LEGEND Attribute definitions
- align =top|bottom|left|right[CI]
- Deprecated. Thisattribute specifies the position of the legend with respect to the fieldset.Possible values:
- top: The legend is at the top of the fieldset. This is thedefault value.
- bottom: The legend is at the bottom of the fieldset.
- left: The legend is at the left side of the fieldset.
- right: The legend is at the right side of the fieldset.
Attributes defined elsewhere
- id,class (document-wide identifiers)
- lang (language information),dir (textdirection)
- title (elementtitle)
- style (inlinestyle information)
- accesskey (accesskeys)
- onclick,ondblclick,onmousedown,onmouseup,onmouseover,onmousemove,onmouseout,onkeypress,onkeydown,onkeyup (intrinsic events)
TheFIELDSET 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.
TheLEGEND element allows authors to assign a caption to aFIELDSET. The legend improves accessibility when theFIELDSET is rendered non-visually.
In this example, we create a form that one might fill out at the doctor'soffice. It is divided into three sections: personal information, medicalhistory, and current medication. Each section contains controls for inputtingthe appropriate information.
<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>
Note that in this example, we might improve the visual presentation of theform by aligning elements within eachFIELDSET (with style sheets), addingcolor and font information (with style sheets), adding scripting (say, to onlyopen the "current medication" text area if the user indicates he or she iscurrently on medication), etc.
In an HTML document, an element must receivefocus from the userin order to become active and perform its tasks. For example, users mustactivate a link specified by theA element in order to follow thespecified link. Similarly, users must give aTEXTAREA 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 atabbing order that specifies the order in whichelements will receive focus if the user navigates the document with thekeyboard (seetabbing navigation). Onceselected, an element may be activated by some other key sequence.
- Select an element through anaccess key(sometimes called "keyboard shortcut" or "keyboard accelerator").
Attribute definitions
- tabindex =number[CN]
- This attribute specifies the position of the current element in the tabbingorder for the current document. This value must be a number between 0 and32767. User agents should ignore leading zeros.
Thetabbing 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:
- Those elements that support thetabindex attribute and assign apositive value to it are navigated first. Navigation proceeds from the elementwith the lowesttabindex value to the element with the highest value. Valuesneed not be sequential nor must they begin with any particular value. Elementsthat have identicaltabindex values should be navigated in the order theyappear in the character stream.
- Those elements that do not support thetabindex 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.
- Elements that aredisabled do not participate inthe tabbing order.
The following elements support thetabindex attribute:A,AREA,BUTTON,INPUT,OBJECT,SELECT,andTEXTAREA.
In this example, the tabbing order will be theBUTTON,theINPUT elements in order (note that "field1" and the button share thesame tabindex, but "field1" appears later in the character stream), and finallythe link created by theA element.
<!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">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>
Tabbing keys. The actual key sequence that causestabbing navigation or element activation depends on the configuration of theuser agent (e.g., the "tab" key is used for navigation and the "enter" key isused to activate a selected element).
User agents may also define key sequences to navigate the tabbing orderin reverse. When the end (or beginning) of the tabbing order is reached, useragents may circle back to the beginning (or end).
Attribute definitions
- accesskey =character[CN]
- This attribute assigns an access key to an element.An accesskey is a single character from the document character set.Note. Authors should consider the input method of the expected readerwhen specifying an accesskey.
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 bytheA 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 theaccesskey attribute:A,AREA,BUTTON,INPUT,LABEL, andLEGEND, andTEXTAREA.
This example assigns the access key "U" to a label associated with anINPUT control. Typing the access key gives focus to the label whichin turn gives it to the associated control. The user may then enter text intotheINPUT area.
<FORM action="..." method="post"><P><LABEL for="fuser" accesskey="U">User Name</LABEL><INPUT type="text" name="user"></P></FORM>
In this example, we assign an access key to a link defined by theAelement. Typing this access key takes the user to another document, in thiscase, a table of contents.
<P><A accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> Table of Contents</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).
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.
Attribute definitions
- disabled[CI]
- When set for a form control, this boolean attribute disables the controlfor user input.
When set, thedisabled attribute has the following effects on anelement:
The following elements support thedisabled attribute:BUTTON,INPUT,OPTGROUP,OPTION,SELECT,andTEXTAREA.
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.
In this example, theINPUT element is disabled. Therefore, it cannotreceive 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 ofthedisabled attribute is through ascript.
Attribute definitions
- readonly[CI]
- When set for a form control, this boolean attribute prohibits changes tothe control.
Thereadonly attribute specifies whether the control may be modified bythe user.
When set, thereadonly attribute has the following effects on anelement:
The following elements support thereadonly attribute:INPUT andTEXTAREA.
How read-only elements are rendered depends on the user agent.
Note. The only way to modify dynamically the value ofthereadonly attribute is through ascript.
The following sections explain how user agents submit form data to formprocessing agents.
Themethod attribute of theFORM element specifies the HTTP methodused to send the form to the processing agent. This attribute may take twovalues:
- get: With the HTTP "get" method, theform data set is appended to the URI specified by theactionattribute (with a question-mark ("?") as separator) and this new URI is sent tothe processing agent.
- post: With the HTTP "post" method, theform 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.
Note. The "get" method restrictsform data set values to ASCII characters. Only the"post" method (withenctype="multipart/form-data") is specified to coverthe entire[ISO10646] character set.
Asuccessful control is "valid" for submission. Every successfulcontrol has itscontrol name paired with itscurrent value as part of the submittedform data set. A successful control must be defined withinaFORM element and must have acontrolname.
However:
- Controls that aredisabled cannot be successful.
- If a form contains more than onesubmit button, onlythe activated submit button is successful.
- All "on"checkboxes may be successful.
- Forradio buttons that share the same value of thename attribute, only the "on" radio button may be successful.
- Formenus, thecontrol nameis provided by aSELECT element and values are provided byOPTIONelements. 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.
- Thecurrent valueof afile select is a list of one or more filenames. Upon submission of the form, thecontents of each file aresubmitted with the rest of the form data. The file contents are packagedaccording to the form'scontent type.
- The current value of an object control is determined by the object'simplementation.
If a control doesn't have acurrent 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:
Hidden controls andcontrols that are not rendered because ofstyle sheet settings may still be successful. For example:
<FORM action="..." method="post"><P><INPUT type="password" name="invisible-password" value="mypassword"></FORM>
will still cause a value to be paired with the name "invisible-password" andsubmitted with the form.
When the user submits a form (e.g., by activating asubmit button), the user agent processes it asfollows.
Aform data set is a sequence ofcontrol-name/current-value pairs constructedfromsuccessful controls
The form data set is then encoded according to thecontent type specified by theenctypeattribute of theFORM element.
Finally, the encoded data is sent to the processing agent designated by theaction attribute using the protocol specified by themethodattribute.
This specification does not specify all valid submission methods orcontent types that may be used with forms. However,HTML 4 user agents must support the established conventions in the followingcases:
- If themethod is "get" and theaction is an HTTP URI, the user agenttakes the value ofaction, 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 themethod is "post" and theaction is an HTTP URI, the user agentconducts an HTTP "post" transaction using the value of theactionattribute and a message created according to thecontent type specified by theenctype attribute.
For any other value ofaction ormethod, behavior is unspecified.
User agents should render the response from the HTTP "get" and "post"transactions.
Theenctype attribute of theFORM element specifies thecontent type used to encode theform 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 onescaping ampersands in URIattribute values.
This is the default content type. Forms submitted with this content typemust 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 ASCIIcode 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 thedocument. The name is separated from the value by`=' andname/value pairs are separated from each other by`&'.
Note. Please consult[RFC2388] for additionalinformation about file uploads, including backwards compatibility issues, therelationship between "multipart/form-data" and other content types, performanceissues, etc.
Please consult the appendix for information aboutsecurity issues for forms.
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 asuccessful 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:
- a "Content-Disposition" header whose value is "form-data".
- a name attribute specifying thecontrol name ofthe corresponding control. Control names originally encoded in non-ASCIIcharacter 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 appropriatecontent 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--
[8]ページ先頭