|Contained in||APPLET, BLOCKQUOTE, BODY, CENTER, DD, DEL, DIV, FIELDSET, IFRAME, INS, LI, MAP, NOFRAMES, NOSCRIPT, OBJECT, TD, TH|
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 server-side script that handles the form submission.
A mailto URI (e.g., mailto:firstname.lastname@example.org) is also allowed as an ACTION, but this is not supported by all browsers. Even on supporting browsers, mailto forms are troublesome in that they fail to provide feedback to the user after the form submission, and browsers may offer a privacy warning before submitting the form with the user's email address.
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. However, 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 more than a few hundred 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 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 2388.
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 ACCEPT attribute gives a comma-separated list of media types accepted for file upload, allowing the browser to filter out inappropriate files. Current browsers generally ignore the ACCEPT attribute.
The TARGET attribute is used with frames to specify the frame in which 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:
In HTML 4, the TARGET attribute value is case-insensitive, so that _top and _TOP both have the same meaning. However, most browsers treat the TARGET attribute value as case-sensitive and do not recognize _TOP as having the special meaning of _top.
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, FORM accepts the following event attributes:
The NAME attribute, added to FORM in HTML 4.01, specifies a name for referring to the form from a client-side script. The ID attribute provides the same functionality, but old browsers such as Netscape 4.x only support the NAME attribute.