Hypermedia: An Introduction--Part 6

Stuart Moulthrop & Nancy Kaplan
University of Baltimore
School of Information Arts and Technologies · Revised 2008

Part 6: Forms

In HTML, a form is a special division of the page designated by a <FORM></FORM> container. Within this container, other tags and containers are used to produce interactive elements. Some of these components, such as check and radio buttons, or type-in fields and text areas, allow the user to make choices or enter information. Others, such as action buttons, activate specific functions.

Forms have always been an important aspect of Web design -- though not the most visually attractive. Now that the Web is used extensively for e-commerce, forms are especially crucial. Forms provide a powerful tool for turning Web pages from static displays into dynamic documents.

Like all sophisticated tools, however, forms are a bit complicated; not so much in themselves as in their integration with other structures. Forms provide the potential for interactivity on Web pages, but in order to process the data they collect, you usually need an external program of some kind, often running on the HTTP server. This is often a script or Web application written in Java, PERL, Python, C++, or some other language. Forms may also pass data to application servers such as ColdFusion, PHP, or a Microsoft .Net server. These mechanisms lie beyond the purview of this introductory course. We'll teach you to build and use forms here, but Web applications and server-side scripting are taught in other, more advanced courses.

There is one important exception to this distinction: JavaScript, to which we come in Part 8. In the technical parlance, form elements are exposed to JavaScript and other Web scripting languages (JScript, VBScript). That means scripts residing entirely on your page can receive and process information from forms -- so at least some limited interactivity can take place without opening new connections to the server. As you'll see, the combination of forms and JavaScript can be powerful indeed. But for the moment, let's concentrate on forms themselves:

6.1 | TECHNICAL ASPECTS OF FORMS

6.1.1 · The <FORM></FORM> Container

The FORM construction is a container. Its initial tag can take several attributes but the most important are METHOD and ACTION.

METHOD specifies how the form data will be passed along by the browser. You can choose between get and post. The get method appends data to a URL (which probably seems a bit strange at first) and thus limits the amount of data you can send to 100 characters. The post method is the more common, because it does not restrict the amount of data you can send.

ACTION tells the form where to send the data collected through its input elements. Often, ACTION specifies the URL of a script intended to handle processing at the server end. (Lots of things besides Web pages can have URLs.)

One useful ACTION that does not require processing on the server, however, is a MAILTO:. Here's a sample of a FORM container specifying that the form's contents be sent via e-mail:

<FORM METHOD="post" ACTION="mailto: iat@ubalt.edu">
			[ form elements go in here ]
		</FORM>

A form with a simple action such as this might be used to solicit comments on a Web page. You could do much the same thing with a MAILTO: link, of course, but as we'll see, form elements (the unstated middle parts in the example above) let you tailor the response more carefully than you could in a simple mail link.

6.1.2 · The <INPUT /> Element

The INPUT element is the most general type of form element. It is a solitary tag used to create the following:

To differentiate among all these varieties, the INPUT element uses the TYPE attribute. Below is a list of common VALUES for the TYPE attribute.

TEXT

An INPUT whose TYPE is "text" usually has three other attributes as well: NAME, SIZE, and MAXLENGTH.

The NAME attribute is an arbitrary designation used to differentiate one input field from another. You must use a unique NAME for each text input field in your form.

The SIZE attribute specifies the width of the INPUT field. Up to now we've sized everything either in pixels or percentage of available space. Forms depart from this pattern. The SIZE attribute of the text input element is measured in characters -- which of course raises some problems. The characters in question are teletype or monofont (usually some variation of Courier), but though all monofont characters have the same width, that width varies with font size, and users are able to change both font face and size for monofont or fixed-width type, when they configure their Web browsers. As a practical matter, you'll need to work out the width of text input boxes by trial and error.

The MAXLENGTH attribute specifies the maximum number of characters a user can type into the field. MAXLENGTH can be a larger value than SIZE (as it is in the sample text field in the first row of the table above). When MAXLENGTH exceeds SIZE, each new character typed in pushes a character out of sight at the left side of the text box. This is not a good practice. Keep SIZE and MAXLENGTH equal.

PASSWORD

An input element whose TYPE is set to password is really just an ordinary text field with one variation: the characters typed in appear as asterisks or bullets so that no one but the user knows what is being typed. NAME, SIZE, and MAXLENGTH are usually set for this element as well.

CHECKBOX

There are two ways to use checkboxes: alone or in groups. If you need only a single checkbox, you simply write this within the FORM container:

<INPUT TYPE="checkbox" NAME="[name]" />

Using programming techniques we won't discuss at this point, it's then possible to detect the state of the checkbox by inspecting the value associated with its name.

A group is constructed by giving each checkbox element in the group the same NAME. Grouping checkboxes makes things a tiny bit easier on the programmer who has to extract their values, though practically speaking you could achieve much the same end by using a series of ungrouped elements (i.e., having unique names)

To identify which box in an exclusive group was checked and which were blank, assign each check box a unique VALUE. For example, to construct a list of subjects in which the user might be interested, I could create a sequence of check boxes like this:

<INPUT TYPE="checkbox" NAME="categories" VALUE="politics" /> politics 
					
<INPUT TYPE="checkbox" NAME="categories" VALUE="international markets" /> international markets 
					
<INPUT TYPE="checkbox" NAME="categories" VALUE="weather" /> weather
					
<INPUT TYPE="checkbox" NAME="categories" VALUE="sports" /> sports

Note that we've echoed the VALUE string as ordinary text following the end of the INPUT tag. We've shown these strings in red above. Though this text is important -- you wouldn't want to present an unlabeled option -- it is not part of the tag and does not need to correspond exactly to the VALUE. Tbus we could have a checkbox whose VALUE is "noWayBud" but whose accompanying text reads, "I disagree" or "Perhaps not."

The page output for the example above is what you see below:

RADIO

Radio buttons work in much the same way as checkboxes, but with a crucial twist: they behave like the mechanical interface of antique car radios (hence the term). The number of people who actually remember these things diminishes with each passing year, so here's a little history lesson. Back in the days of bomb shelters and carburetors, car radios worked like this: pressing the button for a new station caused the button for the previously selected station to pop back into the unpressed position. Only one button could be pressed at a time.

NAMEVALUE

Using radio buttons, the example above would look like this:

<INPUT TYPE="radio" NAME="categories" VALUE="politics" /> politics 
					
<INPUT TYPE="radio" NAME="categories" VALUE="international markets" /> international markets 
					
<INPUT TYPE="radio" NAME="categories" VALUE="weather" /> weather
					
<INPUT TYPE="radio" NAME="categories" VALUE="sports" /> sports

Again, we've echoed the VALUE for each button in plain text outside the tag (shown once again in red), and there's no requirement that the text next to a radio button must be the same as its VALUE string. Here's the markup in action. Try the buttons yourself:

SUBMIT and RESET

Each of these values for the TYPE attribute creates a button with a particular, predefined function. SUBMIT sends the form data to the script specified in the ACTION attribute of the FORM tag. RESET clears any input the user has entered into the form, returning all binary elements (checkboxes, radio buttons) to their unselected state.

The VALUE attribute that goes with this INPUT type specifies the words that appear on the button as its label. Note that you can assign values other than "Submit" and "Reset" to these buttons -- "Send Data" and "Clear Form," for instance -- but keep these values clear and useful.

6.1.3 · Text Areas

This element specifies a free-form input area where your visitors can type whatever they want. Unlike the INPUT elements, <TEXTAREA></TEXTAREA> is a container requiring both a start and an end tag. It is sized by specifying values for two attributes: COLS and ROWS. The code looks like this:

<TEXTAREA COLS="60" ROWS="4">I dare you to type here.</TEXTAREA>

And the output like this:

As in the case of the text and password INPUT types, COLS and ROWS are measured in character dimensions (width and height), and you will once more have to make a best-guess estimate about the exact size of this element.

Instead of a text label, the TEXTAREA element allows for an initial entry into the text box, in this case the phrase "I dare you to type here," shown in red above. This welcoming message can be useful, but keep in mind that users will have to select over it in order to write their own entries.

If you find the horizontal and vertical scrollbars ugly, too bad: there's no way to suppress them. Generally speaking, forms have never been much fun to look at.

6.1.4 · Selection Lists

The SELECT element is used to create static and drop-down menus. The element uses a <SELECT></SELECT> container requiring both a start and an end tag.

It can accept a SIZE attribute to indicate whether the list will appear in a scrolling box (SIZE = "[any value greater than 1]") or a drop-down menu (SIZE="1"). Yes, this is yet another inconsistency, since SIZE here refers neither to pixels nor to characters but to the number of lines displayed. You'll simply have to memorize this along with all the other inconsistent details relating to forms, then reinforce your memory through practice.

By default, the SELECT element permits users to choose only one option from the list. If you want to enable multiple multiple choices, you must use the MULTIPLE attribute. In good XHTML style, you must write this attribute as MULTIPLE="MULTIPLE", just as you did for NOSHADE in the <HR /> tag.

The items in a selection list are marked with <OPTION></OPTION> containers which occur within the <SELECT></SELECT> container. You must include at least one OPTION container.

The markup below creates a drop-down selection list with three choices:


			<SELECT NAME="animals" SIZE="1">


			<OPTION>lions</OPTION>
			

			<OPTION>tigers</OPTION>
			

			<OPTION>bears</OPTION>

</SELECT>

The results look like this; try it out:

The menu "drops" down over the text below it. The value you select is left visible in the window after you release the mouse button.

Note that no VALUE attribute is required for the OPTION element. The text typed between the two halves of the the OPTION tag becomes the text displayed in the list as well as the value passed when the form is submitted.

The same code rendered as a scrolling field with multiple selection possibilities looks like this:


			<SELECT NAME="animals" SIZE="3" MULTIPLE>


					<OPTION>lions</OPTION>
					

					<OPTION>tigers</OPTION>
					

					<OPTION>bears</OPTION>
					

					<OPTION>mice</OPTION>
					

					<OPTION>voles</OPTION>
					

					<OPTION>moles</OPTION>

</SELECT>

Now the results look like this:

If you hold down the shift key before you click, you may select as many options from this list as you like.

Finally, let's suppose you'd like to pull out an item from somewhere within a long list and show it as the initial or default value--for instance, the country name "United States" in a list of all the countries in the world. You do this by adding the attribute SELECTED to the initial <OPTION> tag, thus:


<OPTION SELECTED>United States</OPTION>

Because SELECTED is another flag attribute like MULTIPLE, XHTML style requires it to be written as SELECTED="SELECTED".

6.2 | USING TABLES TO STRUCTURE FORMS

On many occasions you may want to arrange form elements according to some regular grid. Suppose you have six checkboxes that need to be arrayed in two decks. Here's one possible markup for this form:


<form>


<input type="checkbox" value="apex" /> apex

<input type="checkbox" value="beacon" /> beacon

<input type="checkbox" value="camel" /> camel

<br>

<input type="checkbox" value="delight" /> delight

<input type="checkbox" value="egret" /> egret

<input type="checkbox" value="funnel" /> funnel


</form>

The result is what you see below. (We've added a simple, one-cell table to introduce centering and a border. Forms have no alignment or borders.)

As you can see, the options are scattered around the screen in a way that makes reading very difficult. Compare this arrangement:

In this second example, there are actually two tables: an outer, single-celled table to provide the visible border and an inner table with two rows and six cells. Each checkbox INPUT element is contained within one of those cells. Here's the markup for the inner table:


<FORM>

<table cellpadding="10">

<tr>

<td>

<input type="checkbox" value="aspidistra" /> apex

</td><td>
 
<input type="checkbox" value="mayonnaise" /> beacon

</td><td>

<input type="checkbox" value="camelsNose" /> camel

</td>

</tr><tr>

<td>

<input type="checkbox" value="crenellations" /> delight

</td><td>

<input type="checkbox" value="mustardPlaster" /> egret

</td><td>

<input type="checkbox" value="spoon" /> funnel

</td>

</tr>
</table>

</FORM>

If you're a markup purist, you'll notice something disconcerting here: the FORM container begins outside the TABLE container, even though all the elements of the form occur inside the table. Further, form elements and table elements are intermingled. Strange though this may look, it's a very common practice and entirely harmless. In fact, you should use a table to arrange form elements, if your form contains more than a few parts.

If this procedure bothers you, you can begin your form within the table structure. But where? Before or after the first <TR>? Before the first <TD>? Given the intertwining of table and form structures, several alternatives seem equally reasonable.

Note that if you don't put the </FORM> tag outside the table, you'll end up with an extra blank line after the last table row.

END OF PART 6

Index · Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 7 · Part 8 · Part 9 · Top

standard text fields
password fields
check boxes
radio buttons
submit and reset buttons