FORM - Interactive Form

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

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

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

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.

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:

• ONSUBMIT, when the form is submitted;
• ONRESET, when the form is reset.

More Information

• FORM in W3C HTML 4.0 Recommendation
• FORM in W3C HTML 3.2 Recommendation
• FORM in HTML 2.0 Standard
• FORM in WDG HTML 3.2 Reference
• FORM in Learning HTML 3.2 by Examples
• RFC 1867: Form-based File Upload in HTML
• The Common Gateway Interface
• Java Servlets