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 elementand must be nested inside a form element to render at all in Navigator 4 or earlier.

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 valuesin name/value pairsto the server for further processing (or possibly as an email attachment or message with the help of a browser's e-mail module). 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 with 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 W3C recommendations prefer that form controls use their id attributes in name/value pairs. As of Version 6 browsers, however, only the name attribute is recognized as an identifier for the submitted name/value pair.

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 (non-email) message to the server. Data submitted via the GET method is limited in character length, while the POST method offers unlimited data length and no echoed display in the browser's Address box.

Default behavior of the Enter key in forms has evolved into a recognized standard. When a form consists of a single text input element, pressing 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 (with the exception of IE/Mac).

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 return 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. The hyphenated version is from the HTML 4 specification, but IE 5 and later/Windows and Netscape 6 implement the attribute name without the hyphen.

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" and the enctype attribute precedes the action attribute). For privacy reasons, client users are notified of the impending email transmission and have the chance to cancel the message.

Form-mailing capabilities are essentially disabled in Netscape 6 and 7. Implementations across all browsers are very unevenyou may be missing form submissions from many users. If CGI processing of forms is beyond your expertise, search for third-party FormMail services that forward forms to you via email.

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

If an IE user has automatic form completion preference enabled, the autocomplete attribute governs the feature for the entire form. You must also specify vcard-name attributes for text and password type input elements to let the browser pre-fill or assist the entry of a particular named field that matches one of the preferences entries.

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.

The language being used for the element's attribute values and content. A browser can use this information to assist in proper rendering of content with respect to details such as treatment of ligatures (when supported by a particular font or required by a written language), quotation marks, and hyphenation. Other applications and search engines might use this information to aid the selection of spell-checking dictionaries and the creation of indices.

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.

Assigns an identifier to the entire form element. This value is particularly useful in writing scripts for older browsers that reference the form or its nested controls. Newer browsers support the preferred id attribute for this purpose, but the name attribute is still needed for form submission.

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.

If the form is located in a subwindow, and you want the target to be the main window, you must first use a script to assign an identifier to the name property of the main window. Use that name as the value of the form's target attribute.

Strict DTDs for HTML 4 and XHTML do not support the target attribute of any element because frames and windows are outside the scope of pure document markup. In fact, framesetting documents will not validate in the strict environmentthus the purpose of the separate frameset DTDs for HTML 4 and XHTML. If your documents must validate with these strict DTDs, and you wish to support targets, use scripts to set target properties of links, image maps, and forms after the page has loaded.

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