FORMS in HTML
Version 1.3 - July 4, 2005
(This page presumes familiarity with basic HTML. If you wish to refresh the basics, or do not yet have the basics, please see the Basics in HTML page, then click back here for instruction in Forms.)
FORMS are an important part of many web sites. Especially in the area of e-commerce, they are a staple. They are also quite easy to implement, since often only a few commands are needed and one then relies on the visitor’s browser to do the real magic that makes the form look impressive. The one somewhat complicated issue is “shipping” the data once it is collected — so most of the details on that subject are reserved for the end of the article.
As with all of these HTML instruction pages, you may sometimes want to see more details of examples that are given and how they are coded. Feel free to examine the source code of this page. You can do this by right-clicking on the page and selecting View Source. You can then use the Find feature of the text editor (or whatever program you have opening the source code) to jump right to the section you want to examine.
<form> ... </form>
FORM tags. These are the base tags that mark the beginning and end of the form. Everything else on your page pertaining to the form goes between these tags.
<form action="target"> ... </form>
HINT: Setting action= to an email address or URL effectively turns it into a hyperlink.
<form method="post/get"> ... </form>
method="get"- This is the default. It causes the data collected with the form to be submitted as a request appended to a URL, in the form http://www.someURL.com?field1=data1&field2=data2.... Data sent in this form always requires use of the get method. There are limitations, however: Only ASCII characters can be appended in this way, so input including non-ASCII characters requires the post method. Also, get has a limit of 100 characters.
method="post"- This causes the data collected with the form to be transmitted in the body of the request. For example, this is the ideal method for data sent by email.
Generally, always use post unless there is a specific reason to use get. Of course, if you are using a script someone else has written, you will need to use the method that the particular script requires.
HINT: Good programming (script writing) practice generally means that the script should be written to accept data either way you submit it, therefore you can try either get or post and see if it works. However, one cannot always count on someone else having written their script correctly, so it is more practical just to find out how they recommend you send the data.
HINT: One way to combine the best features of both get and post is that, if you use post but attempt to send data as a URL with ?-appended data, it will work — because get, though unspecified, will still be used for that one part of the send, and post for the rest.
<form name="name"> ... </form>
<form enctype="mimetype"> ... </form>
The INPUT tag, which goes inside the FORM tags, is the primary component of forms. There can be, and usually will be, multiple INPUT tags in a given form. These tags provide the familiar input fields of a form, whether they be text boxes, checkboxes, radio buttons, or other input elements. The INPUT tag has a number of important attributes (which, as appropriate, can be combined into a single tag, but are listed separately here for sake of discussion):
TEXT.Creates a text-box for input, such as this:
<form action="sometarget" method="post">Type something in me: <input type="text"> <i>(then press F5 to refresh the page)</i></form>
PASSWORD.Identical with text, except that the input is encoded so that it is not displayed in a readable form on the user’s screen. (The data is transmitted in fully readable form and with no added encryption. It’s just not displayed that way.) Useful for entering things like passwords. For example:
<form action="sometarget" method="post">Type something in me: <input type="password"> <i>(then press F5 to refresh the page)</i></form>
CHECKBOX.This creates a familiar checkbox on the user’s end; on the back end, it is a logical flag that sends an on (true) or off (false) value, according to whether or not the box is checked. (On and off are the defaults. You can, and usually should, alter the on value by using the value= attribute.) Each <input type="checkbox"> has a different name specification to designate the data field that is marked true or false. If you add a checked attribute, the box will be checked by default:
<form action="sometarget" method="post">Unchecked box: <input type="checkbox" name="box1"> Checked box: <input type="checkbox" name="box2" checked></form>
RADIO.This creates a familiar radio button on the user’s end. On the back end, it is a logical flag that sends an on (true) or off (false) value, according to whether or not the box is selected. (On and off are the defaults. You can, and always should, alter the on value by using the value= attribute.) Several <input type="radio"> tags can have the same name specification, but each will have a separate value. Therefore, if you check one, any other checked radio button for the same name will become unchecked. If you add a checked attribute, the radio button will be checked by default:
<form action="sometarget" method="post"><b>COLORS</b> Red: <input type="radio" name="thing1" value="Red"> Blue: <input type="radio" name="thing1" value="Blue" checked> Yellow: <input type="radio" name="thing1" value="Yellow"><br> <b>SHAPES</b> Square: <input type="radio" name="thing2" value="square"> Triangle: <input type="radio" name="thing2" value="triangle" checked> Circle: <input type="radio" name="thing2" value="circle"><br></form>
SUBMIT.Creates a button to submit the data that was input. The default wording on the button is “Submit Query”. For a different label, use the value="label" tag: The exact form of the buttonwill be controlled by the individual browser. If you don’t want the default button type used, or want to control a consistent appearance across various browsers, you can use the STYLE attribute within the INPUT tag just as you could for any other object. For example, the following button was created from the code line:
<input type="submit" value="Submit!" style="font-family : georgia, garamond, serif; font-size : 13px; font-weight : bold; color : white; border : solid 3px lightgrey; background-color: #cc0066; cursor: hand">
IMAGE.A variation of SUBMIT which uses an image of your choice instead of a SUBMIT button. Use the src= attribute to specify the URL of the image. Add HEIGHT, WIDTH, and ALT parameters and, generally, any that you would use in an <img src=> tag. Not all current browsers support this tag.
RESET.Creates a button to reset the form to its default condition. The default wording on the button is “Reset”. For a different label, use the value="label" tag:
BUTTON.Creates a button that says anything you want it to say. Use the value="label" tag, otherwise (like the first button below) it won’t say anything: Most of you consulting the present page will not find the BUTTON option very useful. It requires additional special knowledge outside the scope of the present page. If interested, you can get further information on implementing push-buttons from W3C here.
FILE.Creates a Browse field and button to upload a file. NOTE: If you use type="file", you must use the enctype="multipart/form-data" attribute in the FORM tag. It also usually misbehaves if the FORM tag’s ACTION attribute specifies an email address. This option should only be used with ACTION pointing to a CGI script, ASP page, etc.
HIDDEN.Sometimes a server will require that you send it particular data, but there is no need to display this on the Web page (or, in fact, you don’t want to!). Or perhaps you want to attach a unique “signature” to data coming from a specific form. In that case, use the hidden type, like this:
<textarea> ... </textarea>
TEXTAREA tags go inside the FORM tags. They are an alternative to the index options above, forming a bigger (multiline) text-box. Use a name=x attribute to name it, and rows=n and cols=n to specify the size of the box in lines down and characters across. Text within the TEXTAREA tags (between the opening and closing tags) will prepopulate the field (so VALUE is not used). Maximum size is 215 (32,768) characters. You also can use the attributes disabled and readonly. Here is a sample of a prepopulated box 40 characters across and 5 lines deep:
<button> ... </button>
BUTTON tags go inside the FORM tags. They are an alternative to using a BUTTON option in a TYPE= attribute. Between the opening and the closing tags, you can put pretty much anything you want to appear on the button, much as if you were putting them in a paragraph: Text, images, sounds, etc. Use the type= attribute to specify button, reset, or submit types. Use the value= attribute to specify the initial value of the button.
<select> ... </select>
SELECT tags go inside the FORM tags. This is what you use to make a drop-down selection box. In addition to general attributes such as disabled and name, the following attributes can be used:
<option value="value"> List Item
<optgroup label="group label"> ... </optgroup>
<fieldset> ... </fieldset>
FIELDSET tags. Optional tags that may be used to visually organize forms or other page content. FIELDSET draws a box around a form or other page content, and puts a stylish LEGEND in it. However, it only works on newer browsers (IE 4.0 or later, or Netscape 6). Also, as with most HTML formatting commands, ultimately it is up to the browser how to render this, and for FIELDSET there is considerable difference in how the encompassing box is drawn by different browsers.
NOTE: This present page is a really good example of how different browsers display content differently. View this page in, say, IE 6 and Netscape 6, and you will see quite a number of things displayed very differently, from spacing and sizing to form objects.
Within the FIELDSET tags, use <legend> ... </legend> tags to enclose the text you want to use to label the box. FIELDSET tags are only recommended for use with forms, but they do provide a nice layout option that may be used occasionally for other page composition purposes; for an example, see the Microsoft Knowledge Base Links portal on this site.
HINT: The LEGEND can be formatted with the style attribute, or by other formatting tags applied to the text within the legend, to give more control over the appearance of the fieldset. In the example above, the text has been bolded.
Having addressed the, uh, form of a FORM, we return to the important question of how to make it practical; that is, how to ship the gathered data (specifically, the name and value information and free-entry text for each field) somewhere so that you actually get to use it!
Your basic tools for this purpose are the action and method attributes of the FORM tag as discussed in more detail above. Using the action attribute, you control where the collected data is sent. Using the method attribute, you control how it is sent there. To review, the main “places” that the data can be routed are:
Most often you will route it to an email address or a CGI script. Each of these has special considerations:
I recommend using CGI when possible. It’s the better approach both now and for future development. Nonetheless, both methods are given here out of consideration for the different levels of technical comfort and technical sophistication of people accessing this page.
Using the email address approach is simple and straightforward. Examples are given above with the initial discussion of the action attribute. For email submissions you will always use method="post".
Regarding CGI scripts, I think the best approach will be to give several examples. Below are samples taken from different pages on the present site. For each one, I provide a link to the page where it actually is used, and then the relevant line from the form’s code that pertains to how the data is transmitted. To see this in a larger context, click the link to visit the page where it is actually used, and use your browser’s View Source feature to examine the complete code. (In the examples, I give below only the line that actually indicates where the data is to be sent for processing. In many cases, a script also requires that specific data fields, hidden or otherwise, be passed to it.) The web page creator who is coding the form usually doesn’t need to know anything further than what is required to be sent, and where to send it — the script takes it from there.
Example No. 1: SIGNING THE GUEST BOOK. www.aumha.org/addguest.htm
This employs a PERL script titled guestbook.pl stored on my web server, called by:<form action="guestbook.pl" method=post>
Example No. 2: PAYPAL SUBMISSIONS. www.aumha.org/donate.htm
This employs a CGI script on PayPal’s server titled webscr, called by:<form action="https://www.paypal.com/cgi-bin/webscr" method=post>
Example No. 3: WHOIS SEARCH. www.aumha.org/search.htm
This employs a CGI script titled whois stored on my web server:<form action="/cgi-sys/whois" method=post>
Example No. 4: LOCKERGNOME SUBSCRIPTION. www.aumha.org/support.htm
For comparison, here is an example of shipping instructions using a web page URL. Something on the page must then know how to receive this and act on it.<form action="http://subscribe.pirillo.com/" method=post>