HTML fill-out forms can be used for questionaires, hotel reservations, order forms, data entry and a wide variety of other applications. The form is specified as part of an HTML document. The user fills in the form and then submits it. The user agent then sends the form's contents as designated by the FORM element. Typically, this is to an HTTP server, but you can also email form contents for asynchronous processing.
Forms are created by placing input fields within paragraphs, preformatted text, lists and tables. This gives considerable flexibility in designing the layout of forms.
HTML 3.0 supports the following kinds of fields:
It is expected that future revisions to HTML will add support for audio fields, multi-row entry of database tables, and extending multi-line text fields to support a range of other data types, in addition to plain text. Client-side scripts will provide the means to constrain field values and to add new field types.
This fictitious example is a questionnaire. It uses the INPUT element for simple text fields, radio buttons, checkboxes, and the submit and reset buttons. The TEXTAREA field is used for a multi-line text entry field. The form fields are laid out with several paragraph elements and an unordered list. Notice the use of the NAME attribute to name each field:
<TITLE>Sample Questionaire</TITLE> <H1>Sample Questionaire</H1> <P>Please fill out this questionaire: <FORM METHOD=post ACTION="http://www.hal.com/sample"> <P>Your name: <input name="name" size="48"> <P><input name="male" type=radio> Male <P><input name="female" type=radio>Female Number in family: <input name="family" type=int> <P>Cities in which you maintain a residence: <UL PLAIN> <LI><input name="city" type=checkbox value="kent"> Kent <LI><input name="city" type=checkbox value="miami"> Miami <LI>Others <textarea name="other" cols=48 rows=4></textarea> </UL> <P>Nickname: <INPUT NAME="nickname" size ="42"> <P>Thank you for responding to this questionaire. <P><INPUT TYPE=SUBMIT> <INPUT TYPE=RESET> </FORM>
Every form must be enclosed within a FORM element. There can be several forms in a single document, but the FORM element can't be nested. The browser is responsible for handling the input focus, i.e. which field will currently get keyboard input. Many platforms have existing conventions for forms, for example, using Tab and Shift-Tab to move the keyboard focus forwards and backwards between fields, and using the Enter (aka Return) key to submit the form.
This standard defines and requires support for the HTTP access protocol only. Under any protocol, the submitted contents of the form logically consist of a list of name/value pairs where the names are given by the NAME attributes of the various fields in the FORM. Each field will normally be given a distinct name. Several radio buttons can share the same name, as this is how you specify that they belong to the same control group - at any time, only one button in the group can be selected.
Note: The contents list of name/value pairs excludes unselected radio buttons and checkboxes. In general, any field with a null value can be omitted from the contents list.
HTML 3.0 doesn't provide direct support for constraining the values entered into text fields, or for derived fields whose values are calculated from the values of other fields. Rather than extending the markup to support these features, HTML 3.0 provides a means for associating the form with a script. Support for scripts is not required, however, and the HTML 3.0 specification doesn't cover the scripting languages or the details of their interface with the user agent
The SCRIPT attribute of the FORM element specifies the script via a URI. The user agent down-loads the script and interprets it locally. Scripts handle a variety of messages for individual fields and the form as a whole. These messages correspond to events such as:
Scripts can examine and set properties of fields. They can also examine a small set of standard properties of the user agent, for instance the user's name, the time of day, the type of user agent, and so on.
Scripts can't do anything that might jeopardize the user or the host machine. Scripts can't send messages over the network, or read or write files. The library calls that are allowed are restricted to a very small and well defined set. These precautions are necessary for untrusted scripts. It is envisaged that script interpreters will offer a much wider application programming interface to trusted scripts, as determined on the basis of a digital signature by a trusted third party.