 |
Chapter 10 Forms |
 |
|
Chapter 10 Forms |
|
You create most form elements with the <input> tag.
Use the <input> tag to define any one of a number of common form elements, including text fields, multiple-choice lists, clickable images, and submission buttons. Although there are many attributes for this tag, only the type and name attributes are required for each element (only type for a submission or reset button; see following explanation), and as we describe in detail later, each type of input element uses only a subset of the allowed attributes. Additional <input> attributes may be required based upon which type of form element you specify. Table 10.1 summarizes the various form <input> types and attributes, required and optional.
You select the type of element to include in the form with the <input> tag's required type attribute, and you name the field (used during the form-submission process to the server; see above) with the name attribute. Although the value of the name attribute is technically an arbitrary string, we recommend you use a name without embedded spaces or punctuation. If you stick to just letters and numbers (but no leading digits) and represent spaces with the underscore (_) character, you'll have fewer problems. For example, "cost_in_dollars" and "overhead_percentage" are good choices for element names; "$cost" and "overhead %" might cause problems.
The HTML standard lets you include three types of text entry fields in your forms: a conventional text entry field, a masked field for secure data entry, and a field that names a file to be transmitted as part of your form data. The first two are available with all browsers and accept size, maxlength, and value attributes. The file-selection field accepts only the size and maxlength attributes.
The most useful as well as the most common form input element is the text entry field. A text entry field appears in the browser window as an empty box on one line and accepts a single line of user input that becomes the value of the element when the user submits the form to the server. To create a text entry field inside a form in your HTML document, set the type of the <input> form element to text. Include a name attribute as well; it's required.
What constitutes a line of text differs among the various browsers. Fortunately, HTML gives us a way, with size and maxlength attributes, to dictate the width, in characters, of the text input display box, and how many total characters to accept from the user, respectively. The value for either attribute is an integer equal to the maximum number of characters you'll allow the user to see and type in the field. If maxlength exceeds size, then text scrolls back and forth within the text entry box. If maxlength is smaller than size, there will be extra blank space in the text entry box to make up the difference between the two attributes.
The default value for size is dependent upon the browser; the default value for maxlength is unlimited. We recommend you set them yourself. Adjust the size attribute so that the text entry box does not extend beyond the right margin of a typical browser window (about 60 characters with a very short prompt). Set maxlength to a reasonable number of characters; for example, 2 for state abbreviations, 12 for phone numbers, and so on.
A text entry field is usually blank at first until the user types something into it. You may, however, specify an initial default value for the field with the value attribute. The user may modify the default, of course. If the user presses a form's reset button, the value of the field is reset to this default value. [the section called "Reset buttons"]
These are all valid text entry fields:
<input type=text name=comments> <input type=text name=zipcode size=10 maxlength=10> <input type=text name=address size=30 maxlength=256> <input type=text name=rate size=3 maxlength=3 value="100">
The first example creates a text entry field set to the browser's default width and maximum length. As we argue above, this is not a good idea because defaults vary widely among browsers, and your form layout is sure to look bad with some of them. Rather, fix the width and maximum number of acceptable input characters as we do in the second example: it lets the user type in up to ten characters inside an input box ten characters wide. Its value will be sent to the server with the name "zipcode" when the user submits the form.
The third example field tells the browser to display a 30-character-wide text input box into which the user may type up to 256 characters. The browser automatically scrolls text inside the input box to expose the extra characters.
The last text input field is three characters wide, lets the user type in only three characters, and sets its initial value to 100.
Notice in the second and fourth example fields, it is implied that certain kinds of data are to be entered by the user--a postal code or a numeric rate, respectively. Except for limiting how many, HTML provides no way for you to dictate what characters may be typed into a text input field. For instance, in the last example field, the user may type "ABC" even though you intend it to be a number less than 1,000. Your server-side application must trap erroneous or mistaken input, as well as check for incomplete forms, and send the appropriate error message to the user when things aren't right. That can be a tedious process, so we emphasize again, provide clear and precise instructions and prompts. Make sure your forms tell users what kinds of input you expect from them, thereby reducing the number of mistakes they may make when filling it out.
Like the Lone Ranger, the mask is on the good guys in a masked text field. It behaves just like a conventional text field in a form, except that the user-typed characters don't appear onscreen. Rather, the browser obscures the characters in a masked text to keep such things as passwords and other sensitive codes from prying eyes.
To create a masked text field, set the value of the type attribute to password. All other attributes and semantics of the conventional text field apply to the masked field. Hence, you must provide a name, and you may (we recommend it) specify a size and maxlength for the field, as well as an initial value.
Don't be misled: a masked text field is not all that secure. The typed-in value is only obscured onscreen; the browser transmits it unencrypted when the form is submitted to the server. So, while prying eyes may not see them onscreen, devious bad guys may steal the information electronically.
file selection fields
As its name implies, the field lets users select a file stored on their computer and send it to the server when they submit the form. Although part of the HTML 3.2 standard and documented by Microsoft as being supported, file-selection fields do not work in Internet Explorer 3.0. They do work in Netscape.
The browser presents the file-selection form field to the user like other text fields. With Netscape, it's accompanied by a button labeled "Browse" to its right. Users either type the pathname directly as text into the field or, with the Browse option, select the name of a locally stored file from a system-specific dialog box.
Create a file-selection field in a form by setting the value of the type attribute to file. Like other text fields, the size and maxlength of a file-selection field should be set to appropriate values, with the browser creating a field 20 characters wide, if not otherwise directed. Since file and directory names differ widely among systems, it makes no sense to provide a default value for this field. As such, the value attribute should not be used with this kind of text field.
The Browse button associated with Netscape's file-selection field opens a platform-specific file-selection dialog that allows users to select a value for the field. In this case, the entire pathname of the selected file is placed into the field, even if the length of that pathname exceeds the field's specified maxlength.
Use the accept attribute to constrain the types of files that the browser lets the user select. It's value is a comma-separated list of MIME encodings; users can only select files whose type matches one of those in the list. For example, to restrict the selection to images, you might add accept="image/*" to the file selection <input> tag.
Unlike other form input elements, the file-selection field only works correctly with a specific form data encoding and transmission method. If you include one or more file-selection fields in your form, you must set the enctype attribute of the <form> tag to multipart/form-data and the <form> tag's method attribute to post. Otherwise, the file-selection field behaves like a regular text field, transmitting its value (that is, the file's pathname) to the server instead of the contents of the file itself.
This is all easier than it may sound. For example, here is a form that collects a person's name and favorite file:
![[Graphic: Figure from the text]](./figs/table10.gif)
<form enctype="multipart/form-data" method=post
action="cgi-bin/save_file">
Your name: <input type=text size=20 name=the_name>
<p>
Your favorite file: <input type=file size=20 name=fav_file>
</form>
The data transmitted from the browser to the server for this example form has two parts. The first contains the value for the name field, and the second contains the name and contents of the specified file:
-----------------------------6099238414674 Content-Disposition: form-data; name="the_name" One line of text field contents -----------------------------6099238414674 Content-Disposition: form-data; name="fav_file"; filename="abc" First line of file ... Last line of file -----------------------------6099238414674--
The browsers don't check that a valid file has been specified by the user. If no file is specified, the filename portion of the Content-Disposition header will be empty. If the file doesn't exist, its name appears in the filename subheader, but there will be no Content-Type header or subsequent lines of file content. Valid files may contain nonprintable or binary data; there is no way to restrict user-selectable file types. In light of these potential problems, the form-processing application on the server should be robust enough to handle missing files, erroneous files, extremely large files, and files with unusual or unexpected formats.
The checkbox element gives users a way to quickly and easily select or deselect an item in your form. Checkboxes may also be grouped to create a set of choices, any of which may be selected or deselected by the user.
Create individual checkboxes by setting the type attribute for each <input> tag to checkbox. Include the required name and value attributes. If the item is selected, it will contribute a value when the form is submitted. If it is not selected, that element will not contribute a value. The optional checked attribute (no value) tells the browser to display a checked checkbox and include the value when submitting the form to the server unless the user specifically clicks the mouse to deselect (uncheck) the box.
The browsers include the value of selected (checked) checkboxes with other form parameters when they are submitted to the server. The value of the checked checkbox is the text string you specify in the required value attribute. For example:
<form>
What pets do you own?
<p>
<input type=checkbox name=pets value="dog"> Dog
<br>
<input type=checkbox checked name=pets value="cat"> Cat
<br>
<input type=checkbox name=pets value="bird"> Bird
<br>
<input type=checkbox name=pets value="fish"> Fish
</form>
creates a checkbox group as shown in Figure 10.3.
Although part of the group, each checkbox element appears as a separate choice onscreen. Notice too, with all due respect to dog, bird, and fish lovers, that we've preselected the cat checkbox with the checked attribute in its tag. We've also provided text labels; the similar value attributes don't appear in the browser's window, but are the values included in the form's parameter list if the checkbox is selected and the form is submitted to the server by the user. Also, you need to use paragraph or line-break tags to control the layout of your checkbox group, as you do for other form elements.
In the example, if "Cat" and "Fish" are checked when the form is submitted, the values included in the parameter list sent to the server would be:
pets=cat pets=fish
Radio-button form elements are similar in behavior to checkboxes, except that only one in the group may be selected by the user.[3] Create a radio button by setting the type attribute of the <input> element to radio. Like checkbox elements, radio buttons each require a name and value attribute. Radio buttons with the same name are members of a group. One of them may be initially checked by including the checked attribute with that element. If no element in the group is checked, the browser automatically checks the first element in the group.
[3] Some of us are old enough, while not yet senile, to recall when automobile radios had mechanical pushbuttons for selecting a station. Pushing in one button popped out the previously depressed one, implementing a mechanical one-of-many choice mechanism.
You should give each radio button element a different value, so the server can sort them out after submission of the form.
Here's the previous example reworked so that now you get to choose only one animal as a favorite pet (see Figure 10.4):
![[Graphic: Figure 10-3]](./figs/h2_1003.gif)
<form>
Which type of animal is your favorite pet?
<p>
<input type=radio name=favorite value="dog"> Dog
<br>
<input type=radio checked name=favorite value="cat"> Cat
<br>
<input type=radio name=favorite value="bird"> Bird
<br>
<input type=radio name=favorite value="fish"> Fish
</form>
Again, like the previous example with checkboxes, we've tipped our hat toward felines, making the "Cat" radio button the default choice. If you select an alternative--"Bird," for instance--the browser automatically deselects "Cat." When the form is submitted to the server, the browser includes only one value with the name "favorite" in the list of form parameters; favorite=bird, if that was your choice.
Since one of the elements in a group of radio buttons is always selected, it makes no sense to create a single radio button; they should appear in your documents as groups of two or more. (Use checkboxes for on/off, yes/no types of form elements.)
Although the terminology is potentially confusing, there is another class of buttons for HTML forms. Unlike the radio buttons and checkboxes described above, these special types of <input> form elements act immediately, their effects cannot be reversed, and they affect the entire contents of the form, not just the value of a single field. These "action" buttons (for lack of a better term) include submit, reset, regular, and clickable image buttons. When selected by the user, both the submit and image buttons cause the browser to submit all of the form's parameters to the form-processing server. A regular button does not submit the form, but can be used to invoke JavaScript code to manipulate or validate the form. The reset button acts locally to return a partially filled-out form to its original (default) state. [the section called "JavaScript Event Handlers"]
The submit button (<input type=submit>) does what its name implies, setting in motion the form's submission to the server from the browser. You may have more than one submit button in a form. You may also include name and value attributes with the submit type of input form button.
With the simplest submit button (that without a name or value attribute), the browser displays a small rectangle or oval with the default label "Submit" (see Figure 10.1). Otherwise, the browser will label the button with the text you include with the tag's value attribute. If you provide a name attribute, the value attribute for the submit button will be added to the parameter list the browser sends along to the server. That's good, because it gives you a way to identify which button in a form was pressed, letting you process any one of several different forms with a single form-processing application.
The following are all valid submission buttons:
<input type=submit> <input type=submit value="Order Kumquats"> <input type=submit value="Ship Overnight" name="ship_style">
The first one is also the simplest: the browser displays a button, labeled "Submit," which activates the form-processing sequence when clicked by the user. It does not add an element to the parameter list that the browser passes to the form-processing server and application.
The second example button has the value attribute that makes the displayed button label "Order Kumquats," but like the first example, does not include the button's value in the form's parameter list.
The last example sets the button label and makes it part of the form's parameter list. When clicked by the user, that last example of the submission button adds the parameter ship_style="Ship Overnight" to the form's parameter list.
reset buttons
The reset type of form <input> button is nearly self-explanatory: it lets the user reset--erase or set to some default value--all elements in the form. Unlike the other buttons, a reset button does not initiate form processing. Instead, the browser does the work of resetting the form elements. The server never knows (or cares, for that matter) if or when the user might have pressed a reset button.
By default, the browser displays a reset button with the label "Reset." You can change that by specifying a value attribute with your own button label.
Here are two sample reset buttons:
<input type=reset> <input type=reset value="Use Defaults">
The first one creates a reset button labeled "Reset"; the browser labels the second example reset button with "Use Defaults." They both initiate the same reset response in the browser.
The image type of <input> form element creates a custom button that is a "clickable" image. It's a special button made out of your specified image that, when clicked by the user, tells the browser to submit the form to the server, and includes the x,y coordinates of the mouse pointer in the form's parameter list, much like the mouse-sensitive image maps we discuss in Chapter 7, Links and Webs. Image buttons require a src attribute with the URL of the image file, and you can include a name attribute. You may also use align and border (Netscape only) attributes to control image alignment within the current line of text and the width of the frame that Netscape places around the image, respectively, much like the align and border attributes for the <img> tag (Internet Explorer doesn't border form <input> images). Interestingly, none of the JavaScript event handlers work with this type of form element, despite what the manufacturer's documentation says--not even onClick, which you might expect, since the image acts like the submit input type.
Here are a couple of valid image buttons:
<input type=image src="pics/map.gif" name=map> <input type=image src="pics/xmap.gif" align=top name=map>
The browser displays the designated image within the form's content flow. The second button's image will be aligned with the top of the adjacent text, as specified by the align attribute. Some browsers (Netscape, for instance) also add a border, as it does when an image is part of an anchor (<a> tag), to signal that the image is a form button.
When the user clicks the image, the browser sends the horizontal offset, in pixels, of the mouse from the left edge of the image and the vertical offset from the top edge of the image to the server. These values are assigned the name of the image as specified with the name attribute, followed by ".x" and ".y," respectively. Thus, if someone clicked the image specified above, the browser would send parameters named map.x and map.y to the server.
Image buttons behave much like mouse-sensitive image maps, and, like the programs that process image maps, your form-processing application may use the x,y mouse-pointer parameters to choose a special course of action. You should use an image button when you need additional form information to process the user's request. If an image map of links is all you need, use a mouse-sensitive image map. Mouse-sensitive images also have the added benefit of providing server-side support for automatic detection of shape selection within the image, letting you deal with the image as a selectable collection of shapes. Buttons with images require you to write code that determines where the user clicked on the image and how this position can be translated to an appropriate action by the server.
Using the <input type=button> tag, you can create a button that can be clicked by the user but that does not submit or reset the form. The value attribute can be used to set the label on the button; the name attribute, if specified, will cause the supplied value to be passed to the form processing script.
You might wonder what value such buttons provide. Little or none, unless you supply the onClick attribute, along with a snippet of JavaScript to be executed when the user clicks the button. Thus empowered, regular buttons can be used to validate form contents, update fields, manipulate the document, and initiate all sorts of client-side activity. [the section called "JavaScript Event Handlers"]
You can have several buttons of the same or different types in a single form. Even simple forms have both reset and submit buttons, for example. To distinguish between them, make sure each has a different value attribute, which the browser uses for the button label. Depending on the way you program the form-processing application, you might also make the name of each button different, but it is usually easier to name all similarly acting buttons the same and let the button handling subroutine sort them out by value. For instance:
<input type=submit name=action value="Add"> <input type=submit name=action value="Delete"> <input type=submit name=action value="Change"> <input type=submit name=action value="Cancel">
When the user selects one of these example buttons, a form parameter named action will be sent to the server. The value of this parameter will be one of the button names. The server-side application gets the value and behaves accordingly.
Since an image button doesn't have a value attribute, the only way to distinguish between several image buttons on a single form is to ensure they all have different names.
The last type of form input element we describe in this chapter is hidden from view. No, we're not trying to conceal anything. It's a way to embed information into your forms that cannot be ignored or altered by the browser or user. Rather, the <input type=hidden> tag's required name and value attributes automatically get included in the submitted form's parameter list. These serve to label the form and can be invaluable when sorting out different forms or form versions from a collection of submitted and saved forms.
Another use for hidden fields is to manage user/server interactions. For instance, it helps the server to know that the current form has come from a person who made a similar request a few moments ago. Normally, the server does not retain this information and each transaction between the server and client is completely independent from all other transactions.
For example, the first form submitted by the user might have asked for some basic information, such as the user's name and where they live. Based on that initial contact, the server might create a second form asking more specific questions of the user. Since it is tedious for users to re-enter the same basic information from the first form, the server can be programmed to put those values in the second form in hidden fields. When the second form comes back, all the important information from both forms is there, and the second form can be matched to the first one, if necessary.
Hidden fields may also direct the server towards some specific action. For example, you might embed the hidden field:
<input type=hidden name=action value=change>
Therefore, if you have one server-side application that handles the processing of several forms, each form might contain a different action code to help that server application sort things out.
The style attribute for the <input> tag creates an inline style for the elements enclosed by the tag, overriding any other style rule in effect. The class attribute lets you format the content according to a predefined class of the <input> tag; its value is the name of that class. The style-conscious browsers cannot distinguish between the various input types, so we recommend that if you use style classes at all, use them with the various form input types. However, be aware that the style properties usually don't affect the appearance of the form element itself.
For instance, you may specify that a text input element should have a blue background and use the Arial typeface:
<input type=text name=name style="background: blue; font-family: Arial">
That doesn't mean it will work. A thin border around the text input area will be blue, but the text input box itself will have a white background, and the input text will appear in the default typeface, not in Arial. [the section called "Inline Styles: The style Attribute"] [the section called "Style Classes"]
By default, every element (except hidden elements) is part of the form's tab order. As the user presses the tab key, the browser shifts the input focus from element to element in the form. For most browsers, the order of the elements in the tab order matches the order of the elements within the form tag. With Internet Explorer, you can explicitly control which elements are part of the form's tab order, and the position of those elements within the tab order.
To exclude an element from the tab order, add the notab attribute to the <input> tag. The element will be skipped when the user tabs around the form.
To reposition an element within the tab order, use the taborder attribute. The value of the attribute is the element's desired position in the tab order. If you really want to change a form's tab order, we suggest you include the taborder attribute with every element in the form, with an appropriate value for each element. In this way, you'll be sure to place every element explicitly in the tab order, and there will be no surprises when the user tabs through the form.
JavaScript browsers support five event handlers for the various <input> tag types. The onClick attribute is for when the user clicks a checkbox, radio, reset, or submit button.[4] Use the onSelect, onFocus, onBlur, and onChange event handlers for form text input-related types (text, password, and file) for when the user selects a form input text area to type in some information, moves the mouse into the text input box, moves away from the text input box, and has changed the value of the text, respectively.
[4] Interestingly, the image type of input button does not support any of the JavaScript event handlers; not even onClick, which is supported by the related submit and reset types, nor any of the event handlers that can be used with the <img> tag.
The value of the <input> event handler attribute is--enclosed in quotation marks--one or a sequence of semicolon-separated JavaScript expressions, methods, and function references that the browser executes when the event occurs. For example, you might include an onClick event with the Submit button; it calls a JavaScript routine that verifies the form is completely filled out before it is submitted over the network to a processing server. Other handlers might compute a running total for items checked on a shopping list, for example. See 13.3.3 for more information about JavaScript and event handlers.
|
 |
|
| Form Fundamentals |  |
Multiline Text Areas |
![[Graphic: Figure 10-4]](./figs/h2_1004.gif)