Despite the importance of HTML forms in communication between web page visitors and the server, a FORM element at its heart is nothing more than a container of controls. Most, but not all, form controls are created in the document as INPUT elements. Even if user interaction with INPUT elements is not intended for submission to a server (perhaps some client-side scripting requires interaction with the user), such INPUT elements are contained by a FORM element.

A document may contain any number of FORM elements, but a client may submit the settings of controls from only one form at a time. Therefore, the only time it makes sense to divide a series of form controls into multiple FORM elements is when the control groups can be submitted independently of each other. If you need to logically or structurally group controls while maintaining a single form, use the FIELDSET element to create the necessary subgroupings of controls.

When a form is submitted to the server, all controls that have NAME attributes assigned to them pass both their names and values--in name/value pairs--to the server for further processing (or possibly as an email attachment or message with Navigator). A Common Gateway Interface (CGI) program running on the server can accept and dissect the name/value pairs for further processing (adding a record to a server database or initiating a keyword search, for example). The server program is invoked via URL to the program assigned to the ACTION attribute.

Inside browsers, the submission process consists of a few well-defined steps. The process begins by the browser assembling a form data set out of the name/value pairs of form controls. The name comes from the value assigned to the NAME attribute. A control's value depends on the type of control. For example, a text INPUT element's value is the content appearing in the text box at submission time; for a radio button within a radio group (all of whose NAME attributes are assigned the same value), the value assigned to the VALUE attribute of the selected radio button is inserted into the name/value pair for the radio group.

The second step of submission encodes the text of each name/value pair. A + symbol is substituted for each space character. Reserved characters (as defined by RFC 1738) are escaped, and all other nonalphanumeric characters are converted to hexadecimal representations (in the form %HH, where HH is the hex code for the ASCII value of the character). Name and value components of each name/value pair are separated by an = symbol, and each name/value pair is delimited with an ampersand (&).

In the final step, the METHOD attribute setting determines how the escaped form data set is transmitted to the server. With a METHOD of get, the form data set is appended to the URL stated in the ACTION attribute, separated by a ? symbol. With a METHOD of post and a default ENCTYPE, the data set is transmitted as a kind of (nonemail) message to the server.

Default behavior of the Enter key in forms has evolved into a recognized standard. When a form consists of a single text INPUT element, a press of the Enter (or Return) key automatically submits the form (as if the user had clicked on a SUBMIT button element. If the form consists of two or more text INPUT elements, the Enter (or Return) key does not automatically submit the form.

Form submission can be canceled in modern browsers with the help of scripts that perform validation checking or other functions triggered by the onSubmit event handler. This event fires prior to the form being submitted. If the event handler evaluates to false, the form is not submitted, and the user may continue to edit the form elements.

Intended for use with INPUT elements of type file, the ACCEPT attribute lets you specify one or more MIME types for allowable files to be uploaded to the server when the form is submitted. The predicted implementation of this attribute would filter the file types listed in file dialogs used to select files for uploading. In a way, this attribute provides client-side validation of a file type so that files not conforming to the permitted MIME type are not even sent to the server.

A server advisory (for servers that are equipped to interpret the information) about which character sets it must receive from a client form.

Specifies the URL to be accessed when the form is being submitted. When the form is submitted to a server for further processing, the URL may be to a CGI program or to an HTML page that includes server-side scripts. (Those scripts execute on the server before the HTML page is downloaded to the client.) As a result of the submission, the server returns an HTML page for display in the client. If the returned display is to be delivered to a different frame or window, the TARGET attribute must be specified accordingly.

You may also substitute a mailto: URL for the ACTION attribute value. Navigator turns the name/value pairs of the form into a document for attachment to an email message (or as the message body with the ENCTYPE attribute set to "text/plain"). For privacy reasons, client users are notified of the impending email transmission and have the chance to cancel the message. Internet Explorer through Version 4 does not automatically include form element data inside an email message begun with a mailto: URL.

If you omit the ACTION attribute and the form is submitted, the current page reloads itself, returning all form elements to their default values.

Sets a MIME type for the data being submitted to the server with the form. For typical form submissions (where the METHOD attribute is set to post), the default value is the proper content type. If you include a file INPUT element, specify "multipart/form-data" as the ENCTYPE attribute. And for Navigator, it is usually more convenient to have form data submitted to a mailto: URL to be in the message body instead of as a message attachment. To embed the form data into the message body, set the ENCTYPE to "text/plain".

Forms may be submitted via two possible HTTP methods: get and post. These methods determine whether the form element data is sent to the server appended to the ACTION attribute URL (get) or as a transaction message body (post). In practice, when the ACTION and METHOD attributes are not assigned in a FORM element, the form performs an unconditional reload of the same document, restoring form controls to their default values.

Due to potential problems with internationalization, the get method is deprecated in HTML 4.0. Because so much of the World Wide Web depends on this method and get is the default method on most browsers, the get method is unlikely to go away for a long time.

Assigns an identifier to the entire FORM element. This value is particularly useful in writing scripts that reference the form or its nested controls.

If the HTML document returned from the server after it processes the form submission is to be loaded into a window or frame other than the current window or frame, you can specify where the returned document should load by assigning a window or frame name to the TARGET attribute. Target frame names must be assigned to frames and windows as identifiers. Assign names to frames via the NAME attribute of the FRAME element; assign names to new windows via the second parameter of the window.open() scripting method. If you omit this attribute, the returned document replaces the document containing the FORM element. An identifier other than one belonging to an existing frame or window opens a new window for the returned document.

A FORM element can have only one returned document and one target. If you want a form submission to change the content of multiple frames, you can include a script in the returned document whose onLoad event handler loads or dynamically writes a document into a different frame. (Set the location.href property of each frame to a desired URL.)