Forms Theory

Before we get started on the subject of forms, there is something which needs to be made perfectly clear. It is simply this: I cannot teach you how to create completely functional forms. Why not? Because there is a lot more to a form than the HTML tags.

In fact, the HTML form is, at most, half the story. The other half is a program which resides on the Web server itself. This program is written in a language such as Perl, C/C++, TCL, AppleScript, or another Common Gateway Interface (CGI) language.

I will not be teaching you any of these languages. In the first place, I don't know any of them well enough to feel confident in teaching them. In the second place, even if I did know enough, writing a tutorial for a programming language is a lot more complicated and indescribably more time-consuming than an HTML tutorial, and I'm not getting paid for this. So, you'll need to either know one of these languages, learn one, or find somebody who knows one and is willing to write your programs for you.

So anyway, the role of this CGI program is to accept the data which the user inputs and then do something with it. What does it do? That depends on what the program has been written to do. It could e-mail the data to someone, or add an entry to a database, or write out a text file, or create a customized display, or just about anything else you can think of.

A very common use for HTML forms is creating a feedback form, or other user-response form. Usually, the feedback from the user is e-mailed to somebody. So how does this work?

Where The Data Goes...

Starfleet Command, last I heard. No, wait, wrong Data. Sorry about that.

Actually, data is passed from the HTML form to the CGI program in name-value pairs. The value is whatever the user enters, and the name is the label used to identify that input. Confused yet? Don't be.

Here is an example. Please realize that technically, this is not the way things actually look, but it's close enough for our purposes. Let's say we have a form with three inputs: name, rank, and serial number. The inputs are labeled NAME, RANK, and SN, respectively. The user enters the data "Eric" for the name, "Very Low" for rank, and "123-45-6789" for the serial number.

The data sent to the CGI program would look something like this:

   NAME = Eric
   RANK = Very Low
     SN = 123-45-6789

The program would then do something with each piece of data. For those of you familiar with programming languages, you recognize what's going on here. The labels are variable names, and the inputted data are the values of the variables.

Let me put it another way (those of you who understood the preceding explanation can skip to the next section). Let's say each input is a labelled box. In the preceding example, the labels would be NAME, RANK, and SN. Whatever the user types in for a given box becomes the contents of that box.

The boxes are then all loaded onto a truck (i.e., your connection to the Web server) which hauls them off to the CGI program. The program then unloads the contents of each box and does something with what it finds. What it does depends on how it's been programmed. An overly simple explanation, perhaps, but conceptually accurate.

No Two Names Alike

This leads us to a very important point: no two inputs can share the same name. Each input has to have its own unique identifier, so that the CGI program can figure out which piece of data belongs where. So if I use the name "ssn" to refer to a Social Security Number input, and then later ask for the name of a nuclear submarine, I must use a different name. "sub" would work, as would "boat," but "ssn" is not allowed.

What happens if you do use the same name twice? Well, no error messages will pop up and warn you about it. If you have two inputs with the same name, what will happen is that the browser will assign one or the other of the values which the user inputs to the name. The one which is not assigned will simply disappear. This may lead to odd results from your CGI program, but it isn't the program's fault. It's simply using the value it received, and it has no way of knowing that another value was input and discarded by the browser.

And Then...

This is the part that is different for each different script. The entire preceding section is a fairly generic description, applying to all forms of this type. What each CGI program does is up to its author. For example, let's say we have a program which is supposed to take the name, rank, and serial number and mail the information to an e-mail address.

For the purposes of this example, assume the CGI program is running on a UNIX-based server. The first thing the program does is create a text file containing the information with appropriate labels. The file would look something like this:

   The following information was input by the user...
      Name: Eric
      Rank: Very Low
        SN: 123-45-6789

The CGI program then sends this file over to sendmail, a common UNIX mail utility, along with some subject and destination information which the CGI program has been written to provide to sendmail. The file is then mailed to its intended destination, and arrives looking something like this:

   Date: Fri, 23 Feb 1996 10:35:00 -0500 (EST)
   To: you@your.site
   From: somebody@some.where.org
   Subject: Data for user 'Eric'
   
   The following information was input by the user...
      Name: Eric
      Rank: Very Low
        SN: 123-45-6789

Of course, as I have said, this is but one of the literally infinite number of things which CGI programs can do. It's merely one of the most common.

The FORM Tag

You've probably been wondering how the browser knows where a form begins and ends. For that matter, how does the browser know where to send the data? Yes, of course, to the CGI program, but... where is that program located? The data has to be sent to a specific location.

This is accomplished by using the <FORM> tag. This tag has two attributes which must be used if the form is to have any prayer of working correctly. The attributes are METHOD and ACTION.

Here's what an empty form would look like:

   <FORM method="post" action="/cgi-bin/program1">

   </FORM>

METHOD has two possible values: GET and POST. If you want the data to go from the browser to the CGI program, as discussed below, then use the method POST. I'm not even sure what GET does, to be honest, but as soon as I figure it out I'll explain it (briefly) here.

The ACTION attribute contains the URL of the CGI program which processes the data sent by the browser. In the example above, the program (program1) resides in the cgi-bin directory of the server which contains the form itself. The value of ACTION can be either a relative or a full URL.

Any tag which is allowed inside of the <BODY> container is allowed inside a form. Headings, paragraphs, lists, tables, images, links-- anything and everything goes. In addition, there are certain tags which are allowed to exist inside a form, and nowhere else.

And Now...

...that you've been introduced to what's going on in the background and to the basic form container, let's start learning the HTML tags which create form elements. We'll kick things off with the most pervasive tag, called INPUT, in the next chapter.

Chapter 4 Quiz
Next-- Chapter 5: Forms: INPUT, Part I
Previous -- Chapter 3: Even More Header Elements
Table of Contents
Tutorial Glossary
Tutorial Index
The HTML Laboratory