INPUT - Form Input

The INPUT element defines a form control for the user to enter input. While INPUT is most useful within a FORM, HTML 4.0 allows INPUT in any block-level or inline element other than BUTTON. However, Netscape Navigator will not display any INPUT elements outside of a FORM.

When a form is submitted, the current value of each INPUT element within the FORM is sent to the server as name/value pairs. The INPUT element's NAME attribute provides the name used. The value sent depends on the type of form control and on the user's input.

The type of form control defined by INPUT is given by the TYPE attribute. The default TYPE is text, which provides a single-line text input field. The VALUE attribute specifies the initial value for the text field. The SIZE and MAXLENGTH attributes suggest the number of characters and maximum number of characters, respectively, of the text field.

While the MAXLENGTH attribute can be an effective guide to the user, authors should not depend on the enforcement of a maximum number of characters by the client. A user could copy the HTML document, remove the MAXLENGTH attribute, and submit the form. Thus authors of form handlers should ensure that any necessary input length checks are repeated on the server-side.

The password input type is a variation on the text type. The only difference is that the input characters are masked, typically by a series of asterisks, to protect sensitive information from onlookers. Note, however, that the actual value is transmitted to the server as clear text, so password inputs do not provide sufficient security for credit card numbers or other highly sensitive information.

The following example uses text and password fields with the LABEL element to bind text labels to the INPUT elements:

<P><LABEL ACCESSKEY=U>User name: <INPUT TYPE=text NAME=username SIZE=8 MAXLENGTH=8></LABEL></P>
<P><LABEL ACCESSKEY=P>Password: <INPUT TYPE=password NAME=pw SIZE=12 MAXLENGTH=12></LABEL></P>

The boolean READONLY attribute, new in HTML 4.0 and poorly supported by current browsers, prevents the user from editing the content of the text or password input types. Read-only elements are still submitted with the form. The DISABLED attribute, which applies to all input types but is also poorly supported, disables the control. Disabled elements are read-only elements with the added restrictions that the values are not submitted with the form, the elements cannot receive focus, and the elements are skipped when navigating the document by tabbing.

The radio and checkbox input types provide switches that can be turned on and off by the user. The two types differ in that radio buttons are grouped (by specifying the same NAME attribute on each INPUT) so that only one radio button in a group can be selected at any time. Checkboxes can be checked without changing the state of other checkboxes with the same NAME. The VALUE attribute, required for radio buttons and checkboxes, gives the value of the control when it is checked. The boolean CHECKED attribute specifies that the control is initially checked.

Some browsers require one radio button in a group to be selected at all times. To ensure that an appropriate default choice is made, authors may wish to define one of the radio INPUT elements as CHECKED.

In the following example, only one payment method may be selected by the user since the radio buttons have the same NAME:

The file input type creates a field through which users can upload files from their local computer or network. The VALUE attribute specifies the name of the initial file, but it is typically ignored by browsers as a security precaution. The ACCEPT attribute gives a comma-separated list of media types accepted, allowing the browser to filter out inappropriate files. Current browsers generally ignore the ACCEPT attribute.

A form that includes a file INPUT must specify METHOD=post and ENCTYPE="multipart/form-data" in the <FORM> tag. CGI libraries such as CGI.pm allow simple handling of such forms.

Form-based file upload is unsupported by many currently deployed browsers. Authors should provide alternative methods of input where possible.

The following example allows the user to upload an HTML document for validation:

<FORM METHOD=post ACTION="/cgi-bin/validate.cgi" ENCTYPE="multipart/form-data">
<P>Select an HTML document to upload and validate. If your browser does not support form-based file upload, use one of our <A HREF="methods.html">alternate methods of validation</A>.</P>
<P><INPUT TYPE=file NAME="html_file" ACCEPT="text/html"></P>
<P><INPUT TYPE=submit VALUE="Validate it!"></P>
</FORM>

The hidden input type allows authors to include form data without having it rendered to the user. This is particularly useful in form applications that span several HTML documents; user input can be carried from form to form by hidden INPUTs. Some generalized CGI scripts use hidden INPUTs to define variables for the script, as in the following example, which defines a recipient and subject for the e-mailed contents of a form:

<INPUT TYPE=hidden NAME=recipient VALUE="[email protected]">
<INPUT TYPE=hidden NAME=subject VALUE="Feedback on your HTML Reference">

Note that the fields are "hidden" in the sense that they are not rendered by the browser. Anyone can still view the HTML document's source to find the "hidden" fields.

The TYPE value reset defines a button by which the user can reset the form to its initial values. The optional VALUE attribute of a reset button overrides the browser's default text for the button.

The submit input type defines a button for submitting the form. As with reset, the optional VALUE attribute provides the text of the button. The presence of the NAME attribute will cause the browser to send a name/value pair for the submit button if it is used to submit the form. This allows authors to provide multiple submit buttons and have the form handler take a different action depending on the submit button used.

The image input type specifies a graphical submit button. The SRC attribute must be included to specify the URI of the image. The ALT attribute should be used to give replacement text for those not loading images. ALT is a new addition in HTML 4.0; many browsers rely on either the NAME or VALUE attribute as alternate text, so authors should use all three attributes for the same purpose where possible. The topic of graphical submit buttons for text users is discussed in detail in the article INPUT TYPE=IMAGE for text users?.

When the graphical submit button is clicked, the coordinates of the click are sent with the form submission as name.x=x-value and name.y=y-value where name is the value of the NAME attribute, x-value is the click's pixels from the left of the image, and y-value is the click's pixels from the top of the image. The USEMAP attribute combined with TYPE=image defines a client-side image map that can be used with client-side scripting, but this method is poorly supported. The USEMAP attribute gives the URI of the defining MAP.

The input type button specifies a push button for use with client-side scripting. The VALUE attribute gives the text label of the button. The ONCLICK attribute is typically used to define the action taken when the button is activated. An example follows:

<INPUT TYPE=button VALUE="Hide non-strict attributes" ID=toggler ONCLICK="toggle()">

In this example, the toggle() function, which would be defined earlier in a SCRIPT element, will be executed when the button is clicked. Since the button is only useful with client-side scripting enabled, authors should usually output the <INPUT TYPE=button> tag using the scripting language to avoid providing a non-functioning button to some users. A more complete version of the previous example would thus be as follows:

<SCRIPT TYPE="text/javascript">
<!--
  document.write("<INPUT TYPE=button VALUE=\"Hide non-strict attributes\""
                 + "ID=toggler ONCLICK=\"toggle()\">");
// -->
</script>

The BUTTON element allows richer labels for submit, reset, and push buttons, but a lack of browser support makes INPUT a more reliable choice at this time.

The ACCESSKEY and TABINDEX attributes apply to all input types except hidden. ACCESSKEY specifies a single Unicode character as a shortcut key for giving focus to the form control. Authors can set the access key on the INPUT element or the LABEL element associated with it. Entities (e.g. &eacute;) may be used as the ACCESSKEY value.

The TABINDEX attribute specifies a number between 0 and 32767 to indicate the tabbing order of the element. A form control with TABINDEX=0 or no TABINDEX attribute will be visited after any elements with a positive TABINDEX. Among positive TABINDEX values, the lower number receives focus first. In the case of a tie, the element appearing first in the HTML document takes precedence.

The INPUT element also takes a number of attributes to specify client-side scripting actions for various events. In addition to the core events common to most elements, INPUT accepts the following event attributes:

• ONFOCUS, when the element receives focus;
• ONBLUR, when the element loses focus;
• ONSELECT, when text in an input of type text or password is selected;
• ONCHANGE, when the element loses focus and its value has changed since it received focus.

More Information

• INPUT in W3C HTML 4.0 Recommendation
• INPUT in W3C HTML 3.2 Recommendation
• INPUT in HTML 2.0 Standard
• INPUT in WDG HTML 3.2 Reference
• INPUT in Learning HTML 3.2 by Examples
• RFC 1867: Form-based File Upload in HTML