FORM - Interactive Form

Syntax

<FORM>...</FORM>

Attribute Specifications

ACTION=url (form handler)
METHOD=[ get | post ] (HTTP method for submitting form)
ENCTYPE=ContentType (content type to submit form as)
ACCEPT-CHARSET=Charsets (supported character encodings)
TARGET=FrameTarget (frame to render form result in)
[4.0] ID=string
[4.0] CLASS=string
[4.0] STYLE=string
[4.0] TITLE=string
[4.0] LANG=Language (i.e. RU - Russian)
[4.0] DIR=ltr|rtl
[4.0] SCRIPTING EVENTS=string
ONSUBMIT=Script (form was submitted)
ONRESET=Script (form was reset)

Contents

Contained in

APPLET, BLOCKQUOTE, BODY, CENTER, DD, DEL, DIV, FIELDSET, IFRAME, INS, LI, MAP, NOFRAMES, NOSCRIPT, OBJECT, TD, TH

Description

The FORM element defines an interactive form. The element should contain form controls--INPUT, SELECT, TEXTAREA, and BUTTON--through which the user interacts.

ACTION

When the user submits the form, through an INPUT or BUTTON element with TYPE=submit, the form values are submitted to the url given in FORM's required ACTION attribute. ACTION usually points to a CGI script or Java servlet that handles the form submission.

A mailto url (e.g., mailto:liam@htmlhelp.com) is also allowed as an ACTION, but this is not supported by all browsers. Non-supporting browsers such as Microsoft Internet Explorer 3.x typically will open a blank e-mail message when the user submits a mailto form. Even on supporting browsers, mailto forms are troublesome in that they fail to provide feedback to the user after the form submission.

Free CGI scripts exist for handling forms; some are even remotely hosted for authors whose providers refuse to allow CGI scripts to be run locally.

METHOD & ENCTYPE

How the form input is sent to the server depends on the METHOD and ENCTYPE attributes. When the METHOD is get (the default), the form input is submitted as an HTTP GET request with ?form_data appended to the url specified in the ACTION attribute.

Using the get method allows the form submission to be contained completely in a URL. This can be advantageous in that it permits bookmarking in current browsers, but it also prevents form data from containing non-ASCII characters such as "é" and "©". As well, the amount of form data that can be handled by the get method is limited by the maximum length of the URL that the server and browser can process. To be safe, any form whose input might contain non-ASCII characters or more than 100 characters should use METHOD=post.

With a METHOD value of post, the form input is submitted as an HTTP POST request with the form data sent in the body of the request. Most current browsers are unable to bookmark POST requests, but POST does not entail the character encoding and length restrictions imposed by GET.

The ENCTYPE attribute specifies the content type used in submitting the form, and defaults to application/x-www-form-urlencoded. This content type results in name/value pairs sent to the server as name1=value1&name2=value2... with space characters replaced by "+" and reserved characters (like "#") replaced by "%HH" where HH is the ASCII code of the character in hexadecimal. Line breaks are encoded as "%0D%0A"--a carriage return followed by a line feed.

Authors should generally only use a different ENCTYPE when the form includes a TYPE=file INPUT element, in which case the ENCTYPE should be multipart/form-data and the METHOD must be post. The format of multipart/form-data requests is given in RFC 1867.

Tools such as cg-eye allow authors to easily create and view a request, simulating the submission of a form. However, authors often do not need to concern themselves with the exact format of the submission; CGI libraries including CGI.pm transparently handle get and post submissions sent as application/x-www-form-urlencoded or multipart/form-data.

ACCEPT-CHARSET

The ACCEPT-CHARSET attribute specifies a list of character encodings that are accepted by the form handler. The value consists of a list of "charsets" separated by commas and/or spaces. The default value is UNKNOWN and is usually considered to be the character encoding used to transmit the document containing the FORM.

TARGET

The TARGET attribute is used with frames to specify in which frame the form response should be rendered. If no frame with such a name exists, the response is rendered in a new window unless overridden by the user. Special frame names begin with an underscore:

ONSUBMIT & ONRESET

The FORM 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:

[4.0] ID

The ID attribute uniquely identifies an element within a document. No two elements can have the same ID value in a single document. The attribute's value must begin with a letter in the range A-Z or a-z and may be followed by letters (A-Za-z), digits (0-9), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

The following example uses the ID attribute to identify each of the first two paragraphs of a document:

<P ID=firstp>My first paragraph.</P>
<P ID=second>My second paragaph.</P>

The paragraphs in the example could have style rules associated with them through their ID attributes. The following Cascading Style Sheet defines unique colors for the two paragraphs:

P#firstp {
  color: navy;
  background: transparent
}

P#secondp {
  color: black;
  background: transparent
}

The paragraphs in the initial example could also be used as a target anchor for links:

<P>See <A HREF="#firstp">the opening paragraph</A> for more information.</P>

Note that most browsers do not support the ID attribute for link anchors. For current browsers, authors should use <A NAME>...</A> within the element instead of ID.

Since ID and NAME share the same name space, authors cannot use the same value for an ID attribute and a NAME attribute in the same document. Also note that while NAME may contain entities, the ID attribute value may not.

[4.0] CLASS

The CLASS attribute specifies the element to be a member of one or more classes. Classes allow authors to define specific kinds of a given element. For example, an author could use <CODE CLASS=Java> when giving Java code and <CODE CLASS=Perl> when giving Perl code.

Unlike with the ID attribute, any number of elements can share the same class. An element may also belong to multiple classes; the CLASS attribute value is a space-separated list of class names.

Note that most current browsers do not support multiple classes. Such browsers typically ignore a CLASS attribute that specifies multiple classes.

The CLASS attribute is particularly useful when combined with style sheets. For example, consider the following navigation bar:

<DIV CLASS=navbar>
<P><A HREF="/">Home</A> | <A HREF="./">Index</A> | <A HREF="/search.html">Search</A></P>
<P><A HREF="/"><IMG SRC="logo.gif" ALT="" TITLE="WDG Logo"></A></P>
</DIV>

This example's use of the CLASS attribute allows style rules to easily be added. The following Cascading Style Sheet suggests a presentation for the preceding example:

.navbar {
  margin-top: 2em;
  padding-top: 1em;
  border-top: solid thin navy
}

.navbar IMG { float: right }

@media print {
  .navbar { display: none }
}
[4.0] STYLE

The STYLE attribute allows authors to specify style rules inline for a single occurrence of an element. An example follows:

<P>A popular font for on-screen reading is <SPAN STYLE="font-family: Verdana">Verdana</SPAN>.</P>

When the STYLE attribute is used, a default style sheet language must be specified for the document by setting the Content-Style-Type HTTP header to the media type of the style sheet language. The previous example could use the following META element in the document's HEAD:

<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

In most cases, use of the CLASS or ID attributes is a better choice than using STYLE since ID and CLASS can be selectively applied to different media and since they provide a separation of content and presentation that often simplifies maintenance.

[4.0] TITLE

The TITLE attribute provides a title for an element and is commonly implemented as a "tooltip" on visual browsers, though many browsers lack support for TITLE. The attribute is most useful with A, LINK, IMG, and OBJECT elements, where it provides a title for the linked or embedded resource. Some examples follow:

TITLE is also helpful with the ABBR and ACRONYM elements to provide the long form of the abbreviation. Examples:

Internationalization Attributes

[4.0] LANG

The LANG attribute specifies the language of an element's attribute values and its content, including all contained elements that do not specify their own LANG attribute. While the LANG attribute is not widely supported, its use may help search engines index a document by its language while allowing speech synthesizers to use language-dependent pronunciation rules. As well, visual browsers can use the language's proper quotation marks when rendering the Q element.

The attribute value is case-insensitive, and should be specified according to RFC 1766; examples include en for English, en-US for American English, and ja for Japanese. Whitespace is not allowed in the language code.

Use of the LANG attribute also allows authors to easily change the style of text depending on the language. For example, a bilingual document may have one language in italics if rendered visually or a different voice if rendered aurally. The HTML of such a document might be as follows:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
   "http://www.w3.org/TR/REC-html40/strict.dtd">
<TITLE>Welcome - Bienvenue</TITLE>
<H1>
  <SPAN LANG=en>Welcome</SPAN> -
  <SPAN LANG=fr>Bienvenue</SPAN>
</H1>
<P LANG=en>This paragraph is in English.</P>
<P LANG=fr>Ce paragraphe est en français.</P>
...

A document's primary language may be set using the LANG attribute on the HTML element, or, alternatively, by using the Content-Language HTTP header.

[4.0] DIR

The DIR attribute specifies the directionality of text--left-to-right (DIR=ltr, the default) or right-to-left (DIR=rtl). Characters in Unicode are assigned a directionality, left-to-right or right-to-left, to allow the text to be rendered properly. For example, while English characters are presented left-to-right, Hebrew characters are presented right-to-left.

Unicode defines a bidirectional algorithm that must be applied whenever a document contains right-to-left characters. While this algorithm usually gives the proper presentation, some situations leave directionally neutral text and require the DIR attribute to specify the base directionality.

Text is often directionally neutral when there are multiple embeddings of content with a different directionality. For example, an English sentence that contains a Hebrew phrase that contains an English quotation would require the DIR attribute to define the directionality of the Hebrew phrase. The Hebrew phrase, including the English quotation, should be contained within a SPAN element with DIR=rtl.

[4.0] Scripting Events

A number of attributes that define client-side scripting events are common to most elements. The attribute value is a script--typically a function call or a few short statements--that is executed when the event occurs. The value may contain entities (e.g., &quot;).

The following example features JavaScript code to handle two events of a submit button, giving the user a reminder in the status bar when the mouse moves over the button and clearing the status bar when the mouse moves away. Note that the attribute values are delimited by single quotes since double quotes are used within them.

<INPUT TYPE=submit ONMOUSEOVER='window.status="Did you fill in all required fields?";' ONMOUSEOUT='window.status="";'>

When an event attribute is used, a default scripting language must be specified for the document by setting the Content-Script-Type HTTP header to the media type of the scripting language. The previous example could use the following META element in the document's HEAD:

<META HTTP-EQUIV="Content-Script-Type" CONTENT="text/javascript">

The common event attributes are device-dependent and largely tailored for the graphical user interface. The available events are as follows:

More Information

Sausage Software and the Web Design Group

Copyright © 1998 Sausage Software & Liam Quinn. All rights reserved.

Maintained by Peter Hurst