HTML Forms

Originally, the World Wide Web was envisaged as a tool for make information available by one person to a large number of others - a one-way transaction. Now, the Web is just as much a tool for dialog - for getting information to flow in both directions: from author to user, and from user back again.

Most Web-based communication is based on information flowing from the server to the browser. The browser requests information; the server replies.

As with any communication, a common "language" is used. Web browsers and servers communication using the Hypertext Transfer Protocol, HTTP.

In order to get user information back, something besides HTTP is needed. Hypertext Transfer Protocol wasn't designed for that!

The protocol (language) that's used is called CGI, "Common Gateway Interface".

CGI provides two ways of returning information from the user. These are called "post" and "get".

• Post sends information in the body of a message that the browser sends to the server.
• Get sends the information as part of the URL string back to the server, with user responses following a question mark "?". (Have you ever noticed URLs with question marks in them?)

Of course, the information has to be processed somehow once it gets where it's going! If it's sent by "post" to you, you can read it yourself - though the CGI language makes it a little confusing for people to read directly.

If it's sent to the server as part of a URL, the server needs instructions on how to handle it. Should it put the information away in a database? Should it look something up in a database? Should it reply to the user simply based on the responses in the CGI?

As you know, computers need instructions for everything! These instructions take the form of computer programs, which are translated into the binary language computers understand. Any program that can run on a server can be used to handle information that comes to the server in the CGI "langauge". These programs can be written by programs (you?) in any programming language the server handles. Most commonly used are Visual Basic (VB) script, C++, Perl, and PHP. (These are all taught at WCC, but aren't covered in this module, which focuses on the HTML side of forms.)

Like anything relatively complex, pre-planning is helpful. Here are some of the questions to think about...

We'd like the users to send us some information. It takes care and thought to ask the questions or labels the form so that visitors understand exactly what you want to know. Oh sure - name and address are pretty straight-forward, but not everything is quite that simple. The smart thing is to jot down a list of the information you want, before you start coding HTML.

For example: Sherry Moore, Public Relations Director of the Stony Creek Historical Museum (SCHM), wants volunteers to be able to register on the SCHM Website. In addition to name and contact info, she needs to know when they're available and what kinds of help they can give. Here are some of the facts Sherry needs:

Facts in the first column are easy to explain. How can she phrase questions to get the facts she needs from the second column? Does she need to give some information that might help potential volunteers give her useful information? Would it help to list the kinds of work volunteers could do? Days and times when the museum needs volunteers?

Filling out forms can be confusing - even if they're well designed. Throwing questions at people randomly could easily make them give up. We expect address info to be in a certain order (street, city, state, zip code), but what about other information?

For example: what is the most logical order for Sherry to ask for these facts?

Consider:

• Someone is available 4-6 PM Mondays and 9-noon Saturdays
• What if the museum is closed on Mondays and volunteers aren't needed that day?
• What about a retired person who goes to Florida every winter, but is available to help at other times?
• Someone spends summers in a cottage up north?

With potential situations like these, how should we organize the questions, and what user input fields should we have?

Have you ever tried to fill out a form that doesn't leave enough space for the information it asks for? "How dumb can they get!?!" HTML forms have a variety of ways to get people's input, some of which require size judgements; others don't.

Here are the most often-used types of HTML inputs:

Which do you think would be appropriate for the different types of facts needed for the SCHM volunteer form?

A simple form that asks for only a few facts can be laid out very simply, without much attempt to line up spaces and blanks across the page. But when the form gets more complex, with more inputs and more instructions, it really helps to use a table to get things lined up neatly.

So before coding the form, it's a good idea to sketch out a rough idea of where the labels, instructions, and blanks will be. That will help you decide whether a table is needed.

Sketch out a rough layout for the SCHM volunteer form.

When someone gives us something, it's really nice for them to hear a friendly "Thank you!" in return. Filling mail-in forms is often a thankless task - but on the Web it doesn't have to be!

The simplest response is just a page that says, "Thank you for filling in our form!" (or something like that). A more useful response gives the user feedback specific to what they filled in - perhaps asking them to confirm that the info is correct. This usually requires programming the server's response, but it may well be worthwhile.

What response would you like to receive if you were volunteering to help at the SCHM? What would be the minimum you think is acceptable?

It makes relatively little difference in most cases, but Post works in just about all situations. That's because there are two drawbacks with Get:

• Get information strings are visible to the user in the Address window (though most users ignore them);
• There is a possibility that Get information may be cut off by some servers if they exceed length limits.

In the examples that follow, we'll use the Post method.

Explore several commercial Web sites that use forms, and submit some (as long as you don't have to pay anything or cause a problem). See if you can tell...

• Did they use Get or Post?
• Did the labels and the order of the questions make it clear to you what information to enter?
• Were the input types logical and convenient?
• How was the form laid out? Could you tell if it used a table?
• What response did you get when you submitted the form? Was it appropriate?

There are many options available for forms, but there are also some things all forms need. Let's look at them first; then we can check out the options.

The Form tags

<form ...>
<!-- input and user instructions go here -->
</form>

define the beginning and end of each form. In theory, a page can contain more than one form, but in practice only one is put on each page. That's because only one form can be submitted at a time, and once a form is submitted the user needs to see a new page.

The opening tag needs to contain information about:

• how the form is to be sent to the server: METHOD
• what the server is to do with it when it arrives: ACTION

Method

This tells the browser how to send the info. There are two possible methods: Get and Post.

• GET sends user input to the server in the URL of a message from the browser:
  <form method=GET ...>
• POST sends user input to the server in the body of a message from the browser. (This is usually the better way to send information.)
  <form method=POST ...>

Action

This tells the browser what the server is supposed to do when it receives the info. There are two general techniques:

• Send the information by email to a designated email box. This results in the CGI code with the user input being sent "raw" to the email address. Though the information can be extracted by the person who receives the email, it's not in a very useful format for humans, and it won't be processed automatically.
  <form method=POST action="mailto:frog1945@hotmail.com">
• Give the name of some program on the server to handle the information - this is the usual Action. These programs are generally known as CGI scripts because they handle information coming in CGI format. You can write a CGI program yourself in any of several computer languages, or you can use pre-made scripts available on the Web. CGI scripts allow you to do whatever you want with the information the user sent in, and also to set up whatever reply you think is appropriate for the user.
  <form method=POST action="/usr/local/apache/cgi-bin/formail.pl">

Scripts

In this module, we'll be using the email option, because we don't expect you to have programming knowledge. Also, when you receive email with CGI you'll get a good idea of what CGI actually looks like when it's sent from a browser to a server.

However, there are a number of places where you can get scripts without having to write them.

• CGI Resource Index: http://www.cgi-resources.com/
• Matt's Script Archive: http://www.scriptarchive.com/index.html
• Extropia.com: http://www.extropia.com/applications.html
• Affordable Web Space Design: http://awsd.com/scripts/
• ScriptSearch.com: http://www.scriptsearch.com/

The submit button is the main way to have your users send the information to you. (Also available is the image map, but this is not commonly used, and will not be discussed here.)

In most cases, the submit button is just used to send the info from browser to server. Here's code for the simplest form:

<input type="submit">

This results in a button that says, "Submit Query".

If you don't have any other input, what does this send to the server? Nothing! If the form's Action is "mailto:..." the user will be given a blank email document to fill in.

You can also give the Submit button a Value and a Name. The Name does nothing, but the Value changes the text that appears on the button. You can even create multiple Submit buttons; if you give each a name, they're supposed to send the Value to the server. I've found (in "mailto:" actions at least) that the information is still blank. Here's example code and its output:

Using the code above as your model, create a page for the SCHM with three submit buttons: one for volunteering in the morning, one for afternoon, and one for evening. Change the "mailto:" address to your own, so you can see what is submitted.

When you get the form to show in your browser, test each button and check your email to see what happens.

Text is probably the most common form of information input via forms. There are three options: text boxes, text areas, and password boxes:

Text boxes are for typing short pieces of information.

Here's an example of the simplest code for a text box:

<input type="text" name="Firstname">

The result is a simple box for the user to type in:

This is all you get: no label or clue of any kind what to do with it! Clearly we need more than this. Here's a more complete example:

Text areas offer more space than text boxes, including scrolling. They're ideal for letting the user give you feedback, or for information that doesn't have to be structured ahead of time - or can't be.

Coding textareas is a little different from the inputs we've seen so far. Instead of just one tag, you need an opening and a closing tag. In between, if you like, you can put text you'd like to have appear in the area when the page is first loaded:

<textarea name="comments">Whatever...</textarea>

Usually the space between the tags if left blank, and a prompt is put in above the textarea.

Textareas can hold *lots* of text - over 32,000 characters. Scrollbars will come into action if someone types enough to need them. However, they don't automatically word-wrap unless you put the parameter WRAP in the tag. All the basic text-editing features are available, including quick-keys, copy and paste. (Sorry - no spell-check!)

If you don't give a size, textareas use a default size:

• Height: 4 rows of text
• Width: 40 characters of input

You can control height and width with the ROWS and COLS tags, like this:

<textarea name="comments" WRAP cols="50" rows="6"></textarea>

As an example, here's a simple form to get feedback from SCHM visitors:

Password boxes are just like text boxes, except that when you type in them they show stars instead of letters. That way, people can't see your password if they're looking over your shoulder. However, the contents aren't encrypted, so they could be detected by hackers.

Often, we need to send information to the server that the user isn't typing in. This makes it possible to use more general programs on the server. For example, there is a well-know CGI program called formmail that has been used by thousands of Webmasters to interpret user data. The program is given instructions using hidden fields - information put in by the person writing the form, rather than by the user.

Add these fields to the SCHM form you created above:

• Name
• Street
• City
• State
• Zip
• Type of work preferred
• Comments

Which type of field should each of these be?

When you have choices to offer to people, you can offer them as either radio buttons, check-boxes, or menus.

Named after the type of buttons often found on car radios, these let you pick one and only one "station to listen to".

Coding radio buttons is similar to coding input fields, except that type="radio", and you need to include a VALUE parameter to be returned to the server.

<input type="radio" name="YesOrNo" value="Y">
<input type="radio" name="YesOrNo" value="N">

There aren't any opening or closing tags for radio buttons that are part of a set. All input fields with the same NAME are simply considered by the browser to be part of the same set.

Example: Sherry Moore wants to know what school district the volunteers reside in, so she can arrange learning activities with school teachers. Stony Creek is in the Lincoln Consolidated school district, but other nearby districts may produce volunteers. Here's a form to collect that information:

Checkboxes let you click to check as many options as you like.

Coding checkboxes is similar to coding radio buttons: there are no beginning and ending tags, and members of the same set are identified by their common NAME value:

<input type="checkbox" name="Topping" value="Chocolate">
<input type="checkbox" name="Topping" value="Strawberry">
<input type="checkbox" name="Topping" value="Peanuts">
<input type="checkbox" name="Topping" value="Candy">

Example: Sherry needs to know what type of work volunteers can do. Checkboxes are an ideal way of capturing that information. Here's code to do that:

Menus are used to get the same kinds of information as radio buttons - items where there is one and only one choice for the user. You can use menus rather than radio buttons when there is a long list of options, and you don't want to take up a lot of space on your page listing them all. (Radio buttons are useful when you want your visitors to be able to see all the options at once.)

Code for menus involves two kinds of tags: opening and closing SELECT tags, within which are any number of OPTION tags:

<select name="Flavor">

<option value="Vanilla">Vanilla
<option value="Chocolate">Chocolate
<option value="Strawberry"> Strawberry

</select>

Ordinarily, you can only make one choice on a menu, but with the parameter MULTIPLE you can allow users to select more than one item. (Other options are also available with menus, but for this module, we'll stick to the basics.)

Example: If Sherry wants volunteers to indicate the one day of the week they most prefer to work, we can create her a menu like this:

Code View:

<h3>Stony Creek Historical Museum</h3> <form method=POST action="mailto:frog1945@hotmail.com"> <strong>What day of the week would you most like to work?</strong><br> <select name="PreferredDay"> <option value="Sunday">Sunday <option value="Monday">Monday <option value="Tueday">Tueday <option value="Wednesday">Wednesday <option value="Thursday">Thursday <option value="Friday">Friday <option value="Saturday">Saturday </select> <input type="submit" value="Voluneer!" name="submit2"> </form>

Browser View:

Stony Creek Historical Museum What day of the week would you most like to work? Sunday Monday Tueday Wednesday Thursday Friday Saturday

Add these fields, with appropriate labels, to your SCHM volunteer form:

• School district - use a menu
• Days available to work - use checkboxes
• Age group - use radio buttons to offer these choices: 6-11, 12-18, 19-59, 60 and above.

There are also a number of options which may or may not be available in all browsers, but which you may want to consider. These include hidden fields, a Reset button, using images to submit data, organizing with Fieldset and Legend tags, labels, tab order, disabled fields, keeping users from changing fields, and keyboard shortcuts. We'll only discuss a couple here.

Occasionally, for whatever reason, a visitor wants to start completely over again. Browsers can empty all the fields and let them do that if you include a reset button. These are usually put next to the submit button, but could be placed anywhere in the form.

Coding a reset button is simple:

<input type="reset">

This will cause the browser to show a button simply labelled "Reset". If you like, you can add a VALUE parameter to give a different label to the button.

<input type="reset" value="Start over again">

Code View:

<h3>Stony Creek Historical Museum</h3> <form method=POST action="mailto:frog1945@hotmail.com"> <strong>What day of the week would you most like to work?</strong><br> <select name="PreferredDay"> <option value="Sunday">Sunday <option value="Monday">Monday <option value="Tueday">Tueday <option value="Wednesday">Wednesday <option value="Thursday">Thursday <option value="Friday">Friday <option value="Saturday">Saturday </select> <input type="submit" value="Voluneer!" name="submit2">&nbsp; <input type="reset" value="Start over again"> </form>

Browser View:

Stony Creek Historical Museum What day of the week would you most like to work? Sunday Monday Tueday Wednesday Thursday Friday Saturday

 

Many people move from one field to another using the mouse, but it's also possible to use the Tab key. The Tab key can speed things up, especially on long, tiresome forms. In simple forms, the Tab key will take users to the next field in an intuitive way, but when tables with multiple columns are used, the Tab key may lead people in strange and confusing ways.

Coding tab order is done by adding a TABINDEX parameter to any of the input tags:

First name: <input type="text" name="FirstName" tabindex="1">
Last name: <input type="text" name="LastName" tabindex="2">

One hitch with tab order in some browsers is that the first time someone presses the Tab key, input goes to the browser's URL window rather than to the first field in the tab order. You can think of the URL window in these browsers always having a tabindex of zero. In addition to form fields and buttons, tab order can also be assigned to links by adding the TABINDEX parameter to them.

Example: using a four-column table can make the form for entering name and contact info much neater, but it can also result in the tab order being strange. The first example shows a table without tab order. (To save space, the code isn't shown.) Try using the Tab key to move from one field to the next - it follows the HTML code order, not the logical sequence:

The second example shows the same code, but with tabindex in each input field. (Notice the SIZE parameter used to control field length in all input fields, and MAXLENGTH used to limit user input in the State and Zip fields.)

	<table border=0 cellpadding=4 align=center>
     <tr>
			<td align="right">First name:</td>
			<td><input type="text" name="FirstName" size=20 tabindex=1></td>
			<td align="right">Street:</td>
			<td><input type="text" name="Street1" size=40 tabindex=5></td>
		</tr>
		<tr>
			<td align="right">Last name:</td>
			<td><input type="text" name="LastName" size=20 tabindex=2></td>
			<td align="right">Apartment or PO Box:</td>
			<td><input type="text" name="Street2" size=40 tabindex=6></td>
		</tr>
		<tr>
			<td align="right">Phone:</td>
			<td><input type="text" name="Phone" size=20 tabindex=3></td>
			<td align="right">City:</td>
			<td><input type="text" name="City" size=40 tabindex=7></td>
		</tr>
		<tr>
			<td align="right">Email:</td>
			<td><input type="text" name="Email" size=20 tabindex=4></td>
			<td align="right">State, Zip:</td>
  	<td>	<input type="text" name="State" size=2 maxlength=2 tabindex=8>
				<input type="text" name="Zip" size=10 maxlength=10 tabindex=9>
			</td>
		</tr>
	</table>

			  

Audience:

Objectives:

When you successfully complete this lesson, you will be able to...

1. Discuss the process of sending information from a Web page to a server and back again;
2. Define CGI, "Common Gateway Interface";
3. Discuss the two methods for sending information to a server;
4. Discuss the types of action available for handling Web input;
5. Discuss the parts of an HTML form;
6. Discuss the HTML tag used in creating a form, and the options available in it;
7. Discuss the reason for each input to have a unique name;
8. Name the HTML tags used to create each of the possible types of input, including
   1. text boxes and the options available with this tag;
   2. password boxes;
   3. text areas and the options available with this tag;
   4. radio buttons;
   5. checkboxes;
   6. menus (select...option)
   7. hidden fields
   8. submit and reset buttons
9. Discuss extra attributes, including tab order, keyboard shortcuts, and disabled elements

Module W26c:

Author:

Institution: