Which of the following is a valid entry for the tab stop property of a form control?

17 Forms

Contents

1. Introduction to forms
2. Controls
   1. Control types
3. The FORM element
4. The INPUT element
   1. Control types created with INPUT
   2. Examples of forms containing INPUT controls
5. The BUTTON element
6. The SELECT, OPTGROUP, and OPTION elements
   1. Pre-selected options
7. The TEXTAREA element
8. The ISINDEX element
9. Labels
   1. The LABEL element
10. Adding structure to forms: the FIELDSET and LEGEND elements
11. Giving focus to an element
    1. Tabbing navigation
    2. Access keys
12. Disabled and read-only controls
    1. Disabled controls
    2. Read-only controls
13. Form submission
    1. Form submission method
    2. Successful controls
    3. Processing form data
       • Step one: Identify the successful controls
       • Step two: Build a form data set
       • Step three: Encode the form data set
       • Step four: Submit the encoded form data set
    4. Form content types
       • application/x-www-form-urlencoded
       • multipart/form-data

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. Users generally "complete" a form by modifying its controls [entering text, selecting menu items, etc.], before submitting the form to an agent for processing [e.g., to a Web server, to a mail server, etc.]

Here's a simple form that includes labels, radio buttons, and push buttons [reset the form or submit it]:

 
    

    First name: 
              

    Last name: 
              

    email: 
              

     Male

     Female

     
    
 

Note. This specification includes more detailed information about forms in the subsections on form display issues.

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 a control within a FORM element is the FORM element.

Each control has both an initial value and a current value, both of which are character strings. Please consult the definition of each control for information about initial values and possible constraints on values imposed by the control. In general, a control's "initial value" 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 of an OBJECT element in a form is determined by the object implementation [i.e., it lies outside the scope of this specification].

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

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

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

17.2.1 Control types

HTML defines the following control types:

buttonsAuthors may create three types of buttons:

• submit buttons: When activated, a submit button submits a form. A form may contain more than one submit button.
• reset buttons: When activated, a reset button resets all controls to their initial values.
• push buttons: Push buttons have no default behavior. Each push button may have client-side scripts associated with the element's event attributes. When an event occurs [e.g., the user presses the button, releases it, etc.], the associated script is triggered.

  Authors should specify the scripting language of a push button script through a default script declaration [with the META element].

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

Note. Authors should note that the BUTTON element offers richer rendering capabilities than the INPUT element.

checkboxesCheckboxes [and radio buttons] are on/off switches that may be toggled by the user. A switch is "on" when the control element's checked attribute is set. When a form is submitted, only "on" checkbox controls can become successful.

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

radio buttonsRadio buttons are like checkboxes except that when several share the same control name, they are mutually exclusive: when one is 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" is undefined. Note. Since existing implementations handle this case 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 elements of a set of radio buttons specifies `CHECKED', then the user agent must check the first radio button of the set initially.

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

menusMenus offer users options from which to choose. The SELECT element creates a menu, in combination with the OPTGROUP and OPTION elements. text inputAuthors 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 current value. file selectThis control type allows the user to select files so that their contents may be submitted with a form. The INPUT element is used to create a file select control. hidden controlsAuthors may create controls that are not rendered but whose values are submitted with a form. Authors generally use this control type to store information between client/server exchanges that would otherwise be lost due to the stateless nature of HTTP [see [RFC2616]]. The INPUT element is used to create a hidden control.object controlsAuthors may insert generic objects in forms such that associated values are submitted along with other controls. Authors create object controls with the OBJECT element.

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

17.3 The FORM element

Start tag: required, End tag: required

Attribute definitions

action = uri [CT]This attribute specifies a form processing agent. User agent behavior for a value other than an HTTP URI is undefined.method = get|post [CI]This attribute specifies which HTTP method will be used to submit the form data set. Possible [case-insensitive] values are "get" [the default] and "post". See the section on form submission for usage information.enctype = content-type [CI]This attribute specifies the content type 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 in combination with the INPUT element, type="file".accept-charset = charset list [CI]This attribute specifies the list of character encodings for input data that is accepted by the server processing this form. The value is a space- and/or comma-delimited list of charset values. The client must interpret this list as an exclusive-or list, i.e., the server is able to accept any single character encoding per entity received.

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

accept = content-type-list [CI]This attribute specifies a comma-separated list of content types that a server processing this form will handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server [cf. the INPUT element when type="file"].name = cdata [CI] This attribute names the element so that it may be referred to from style sheets or scripts. Note. This attribute has been included for backwards compatibility. Applications should use the id attribute to identify elements.

Attributes defined elsewhere

• id, class [document-wide identifiers]
• lang [language information], dir [text direction]
• style [inline style information]
• title [element title]
• target [target frame information]
• onsubmit, onreset, title, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup [intrinsic events]

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 action attribute]. The receiving program must be able to parse name/value pairs in order to make use of them.
• The method by which user data will be sent to the server [the method attribute].
• A character encoding that must be accepted by the server in order to handle this form [the accept-charset attribute]. User agents may advise the user of the value of the accept-charset attribute and/or restrict the user's ability to enter unrecognized characters.

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

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

 
 ...form contents...
 

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

Note. Further discussion on the behavior of servers that receive form data is beyond the scope of this specification.

17.4 The INPUT element

Start tag: required, End tag: forbidden

Attribute definitions

type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI] This attribute specifies the type of control to create. The default value for this attribute is "text".name = cdata [CI]This attribute assigns the control name.value = cdata [CA]This attribute specifies the initial value of the control. It is optional except when the type attribute has the value "radio" or "checkbox".size = cdata [CN]This attribute tells the user agent the initial width of the control. The width is given in pixels except when type attribute has the value "text" or "password". In that case, its value refers to the [integer] number of characters.maxlength = number [CN]When the type attribute has the value "text" or "password", this attribute specifies the maximum number of characters the user may enter. This number may exceed the specified size, in which case the user agent should offer a scrolling mechanism. The default value for this attribute is an unlimited number.checked [CI]When the type attribute has the value "radio" or "checkbox", this boolean attribute specifies that the button is on. User agents must ignore this attribute for other control types.src = uri [CT]When the type attribute has the value "image", this attribute specifies the location of the image to be used to decorate the graphical submit button.

Attributes defined elsewhere

• id, class [document-wide identifiers]
• lang [language information], dir [text direction]
• title [element title]
• style [inline style information]
• alt [alternate text]
• align [alignment]
• accept [legal content types for a server]
• readonly [read-only input controls]
• disabled [disabled input controls]
• tabindex [tabbing navigation]
• accesskey [access keys]
• usemap [client-side image maps]
• ismap [server-side image maps]
• onfocus, onblur, onselect, onchange, title, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup [intrinsic events]

17.4.1 Control types created with INPUT

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

textCreates a single-line text input control.passwordLike "text", but the input text is rendered in such a way as to hide the characters [e.g., a series of asterisks]. This control type is often used for sensitive input such as passwords. Note that the current value is the text entered by the user, not the text rendered by the user agent.

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

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

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

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

• Use multiple submit buttons [each with its own image] in place of a single graphical submit button. Authors may use style sheets to control the positioning of these buttons.
• Use a client-side image map together with scripting.

resetCreates a reset button.buttonCreates a push button. User agents should use the value of the value attribute as the button's label.hiddenCreates a hidden control.fileCreates a file select control. User agents may use the value of the value attribute as the initial file name.

17.4.2 Examples of forms containing INPUT controls

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

 
    

    First name: 

    Last name: 

    email: 

     Male

     Female

     
    
 

This form might be rendered as follows:

W3C Web site. ...some more... Get the current database. ...some more...

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

17.11.2 Access keys

Attribute definitions

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

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

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

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.

User Name

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.

    Table of Contents

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

17.12 Disabled and read-only controls

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

17.12.1 Disabled controls

Attribute definitions

disabled [CI]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:

• Disabled controls do not receive focus.
• Disabled controls are skipped in tabbing navigation.
• 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 inherited value.

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 INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.

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

17.12.2 Read-only controls

Attribute definitions

readonly [CI]When set for a form control, this boolean attribute prohibits changes to the control.

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

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

• Read-only elements receive focus but cannot be modified by the user.
• Read-only elements are included in tabbing navigation.
• Read-only elements may be successful.

The following elements support the readonly attribute: INPUT 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.

17.13 Form submission

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

17.13.1 Form submission method

The method attribute of the FORM element specifies the HTTP method used to send the form to the processing agent. This attribute may take two values:

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

The "get" method should be used when the form is idempotent [i.e., causes no side-effects]. Many database searches have no visible side-effects and make ideal 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 restricts form data set values to ASCII characters. Only the "post" method [with enctype="multipart/form-data"] is specified to cover the entire [ISO10646] character set.

17.13.2 Successful controls

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

However:

• Controls that are disabled cannot be successful.
• If a form contains more than one submit button, only the 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 name is provided by a SELECT element and values are provided by OPTION elements. Only selected options may be successful. When no options are selected, the control is not successful and neither the name nor any values are submitted to the server when the form is submitted.
• The current value of a file select is a list of one or more file names. Upon submission of the form, the contents of each file are submitted with the rest of the form data. The file contents are packaged according to the form's content type.
• The current value of an object control is determined by the object's implementation.

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

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

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

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

will still cause a value to be paired with the name "invisible-password" and submitted with the form.

17.13.3 Processing form data

When the user submits a form [e.g., by activating a submit button], the user agent processes it as follows.

Step one: Identify the successful controls 

Step two: Build a form data set 

A form data set is a sequence of control-name/current-value pairs constructed from successful controls

Step three: Encode the form data set 

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

Step four: Submit the encoded form data set 

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

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

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

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 agents must support the content types listed below. Behavior for other content types is unspecified.

Please also consult the section on escaping ampersands in URI attribute values.

application/x-www-form-urlencoded  

This is the default content type. Forms submitted with this content type must 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 ASCII code 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 the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.

multipart/form-data  

Note. Please consult [RFC2388] for additional information about file uploads, including backwards compatibility issues, the relationship between "multipart/form-data" and other content types, performance issues, etc.

Please consult the appendix for information about security issues for forms.

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

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

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

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

Each part is expected to contain:

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

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

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

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

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

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

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

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

 
   

   What is your name? 

   What files are you sending? 

    
 

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

Which control allows you to type an entry or choose an entry from a list?

Which two properties control how a form and subform are linked?

Which control allows you to type an entry or choose an entry from a list quizlet?

Which of the following steps removes the page header and page footer sections from a report in report design view?