Intermediate HTML
Intermediate HTML
DISCLAIMER: I believe the information on this page is still correct, but since I have written I have had little personal experience with forms and there are all kinds of ways to construct them (with Javascript, for example) that are probably superior to the primitive methods described here, but of which I do not have working knowledge. There are also services like Wufoo.com. It's free for a minimal number of forms, but they also offer a pay service if you have a lot of forms you need to develop.
It might seem odd to start our discussion of forms with the last step, their processing, but you have to know how the contents of the forms are going to be sent to you to start the coding. For most forms applications, you will need to use a script stored on your Web site's server to process the input. On the Library server, for example, there is a script called wsendmail, referred to in our forms coding as http://library.stmarytx.edu/cgi-bin/wsendmail.exe. Consult with your webmaster or hosting service to find out what, if any, scripts are available for you to use. You also need to find out what additional fields are required so that the output of the script can be sent correctly. Again using the Library server as an example, this is how I start off a form which calls upon this script:
<form method="post"
action="http://library.stmarytx.edu/cgi-bin/wSendmail.exe">
<input type=hidden name="name" value="value">
<input type=hidden name="RCPT"
value="kamen@stmarytx.edu">
You can have forms input sent to you without a script, as an email message. But unless the form is very brief, the information you get will be difficult to decipher. Look at a comparison of the output from a mailto and a script to see what I mean. On some browsers, too, a rather ominous-sounding message displays when your users submit their mailto input. However, this is an alternative if you don't have a script available. My forms example page (showing all types of coding and layout options) is set up as a mailto form so that you can see how that is done. (This is example is a frameset. If you can't or don't want to look at frames, here is a link to the forms display page; you can see the coding in Page or Document Source.)
In the examples below, for the sake of simplicity, I am just making up a script name—script.cgi—and inserting it where you would normally put a reference to your server's script.
Caveat: I have not used forms on my own pages extensively and therefore know less about this feature than anything else in this guide. I am confident the information below is correct, but I probably will be unable to answer questions that go much beyond what is here. Again, I refer you to the wonderful resources in Good and Cited Sites for more information.
The basic tags that enclose your form content and formatting are <form></form>. forms can be intermingled with regular text, placed in table cells, or used in conjunction with lists. They can ask for input from users in several different ways, and there are different ways the coding can be set up to make processing the responses easier.
First, the <form> opening tag requires two attributes: action and method. Action is where you specify the location of the script file that will process your form's responses. This is the format for the tag and attributes:
<form action="script.cgi" method=post>
There are some other possible values for method, but since post is the one normally recommended, it's what I will be using in my examples. The next few lines may need to contain information for the script. For example, for a form using the Library's server script, you need to have these lines, identifying the expected output and giving the script an email address to which it will be sent:
<input type=hidden name="name"
value="value">
<input type=hidden name="rcpt"
value="kamen@stmarytx.edu">
Then comes the coding that will determine what your users see on their screen, the <input> tags. These tags require a type attribute. They may also have name and value attributes and others such as size which will regulate their appearance on the page.
The type attribute determines what kind of buttons, bars or spaces your user will see and what kind of response they will be allowed to make. Name and value attributes will be attached to the responses by the processing script. (After you're familiar with the types of input, look at my forms example page and the output from it for some insight into how name and value attributes can help you decipher and analyze responses.) Here are the six major types of input specifiers (examples will follow):
| type | Description | Response allowed |
|---|---|---|
| text | text entry field | -single line of user-chosen text -there can be default text entered |
| checkbox | box for checking | -0, 1 or more can be checked with mouse click -name attribute required -value, checked attributes optional |
| radio | toggle buttons | -only 1 may be checked -name attribute required -value, checked attributes optional |
| <textarea> | text entry field | -longer user-chosen text responses allowed, up to limit specified with ROW, COL attributes -optional attribute WRAP turns word-wrap on in text area -requires a closing tag </textarea> |
| <select> | Scrollable list or pop-up menu |
-requires a closing tag </select> |
| reset | reset button | -clicking this button resets form to default values -optional value attribute labels button (default is "Reset") |
| submit | submission button | -clicking this button submits responses to script or email -optional value attribute labels button (default is "Submit Query") |
Now we'll look at each of these types in detail.
The simplest form input field is text. The coding on the right creates the one-line text-entry field on the left:
| <input type=text name="sample"> |
The name attribute is required, but since I don't know what's going to be asked for in this text field, I can't give it a meaningful name. If I added some text, the example would make more sense:
Enter your name here:
| <input type=text name="user"> |
Now the name attribute makes sense. When the input is sent to me from the script, the tag "user" will be attached to whatever my users type in the box. The phrase "Enter your name here" comes before the input element, but within the<form></form> tags. This is an example of what I meant by interspersing forms and text above.
NOTE: <input> tags are not paired.
You can make the text-entry box a different size than the default (20 characters) by adding a size attribute. A different optional attribute, max length (value must be an integer) sets a maximum length that will be accepted by the field. If max length is greater than size, the field will automatically scroll.
Checkboxes and radio buttons are similar in function but each one looks a little different, and with radio buttons only one of a group can be checked. Clicking on one of them turns the others in the group "off." With checkboxes, as many can be checked as the user wants.
For these types of input fields, use a non-paired <input> tag to start with. The following coding would result in the little form below it:
What type of computer do you use? (NOTE: this is text typed before the input elements.)
<input type=checkbox name="computer"
value="mac">Macintosh
<input type=checkbox name="computer" value="pc">IBM-type PC
What type of computer do you use?
A user responding to this question could check both boxes (although this is not likely to be an accurate answer to the question!). Their input would be sent to you by the script with the name "computer" and the appropriate value (mac or pc) attached.
Compare a similar form using radio buttons:
Do you run Windows 3.1 or Windows 95/8?
<input type=radio name="os" value="3">Windows
3.1
<input type=radio name="os" value="95">Windows 95/8
Do you run Windows XP or Windows 98?
| (Only one of these options could be checked and sent to you, with the name "os" and the appropriate value attached) |
For both checkboxes and radio buttons, you can make one selection checked as a default by adding the attribute checked to the input tag.
To allow your users more room for comments or other responses than the one line allowed in a text input field, use the<textarea></textarea> tags. The syntax for this kind of field is different in that you don't type <input> first, and the tags must be paired. In between the opening and closing tags you can type some default text that will appear in the text-entry field. You don't have to have default text, however. Here is some sample textarea coding and its result:
<textarea name="comment" rows=5 cols=25 wrap >
type your comments
here: </textarea>
| The number values of the rows and cols attributes refer to lines and characters, respectively. When you include the attribute wrap, word wrap applies within the box. Without it, users have to hit returns at the end of a line. |
The <select></select> tags are used to create more complex displays of choices: popup menus and scrolling lists. The syntax for these forms resembles that for lists. The <select></select> tags frame the choices, which are coded in non-paired option tags. (NOTE: XHTML standards require <option> tags to be paired.)
This is the coding for the pop-up menu that is displayed below:
<select name="movies">
<option>Citizen Kane
<option>The Godfather, Part II
<option>Raging Bull
<option>The Great Train Robbery
</select>
The text typed after the <option> tags is what will appear in the menu box. If you want something else attached to the input when the script sends it to you, add an optional value attribute to the <option> tag:
<option value="kane">Citizen Kane
Here is the way this pop-up menu would appear on your page:
| Which movie is the greatest ever made? |
The text to the right of the menu must be typed before the select element.
To make a scrolling list instead of a pop-up menu, you just need to add a size attribute (with a value of more than 1) to the <select> tag. Addition of another attribute, multiple, allows more than one selection to be checked:
<select name="movies" size=2 multiple
>
<option>Citizen Kane
<option>The Godfather, Part II
<option>Raging Bull
<option>The Great Train Robbery
</select>
Here is what this scrolling list would look like, along with a question typed before the select element:
| Which of these movies have you seen? |
The size attribute gives the number of choices that will be visible in the list initially. If you have more options listed, the list will scroll; if not, then it won't.
For both pop-up menus and scrolling lists, you can make one choice selected as a default by adding the attribute selected to the option tag.
You may want to give your users the opportunity to clear their selections
and start over. This is accomplished with a
reset button. The default text that will
appear on the button is "reset." You can change this with a
value attribute. For this kind of button,
a name attribute is not necessary:
| <input type=reset value="clear"> |
When your users are ready to submit their input, they will click on a submit button which is coded this way:
<input type=submit value="Send us your input">
You can add a name attribute to the button coding, but it is not necessary. The value attribute, also optional, replaces the default text of submit query with something that makes more sense in the context of your form. The button will automatically resize to fit whatever text you assign to the value attribute.
There are a few other types of input fields that can be included in your forms, but they are not as commonly used and are beyond the scope of this simple introduction. Here are brief descriptions of them; for more information, check some of the General Resources listed in Good and Cited Sites.
A password field is just the same as a one-line text field, but the browser will not display what the user types in the box. However, using this kind of field only guards against someone seeing a password over the user's shoulder. It does not hide the password or encode it in any way. Much more complicated work is required to conduct truly secure communications.
Hidden fields convey information to the script that you don't want displayed. Immediately after the <form> tag, for example, the script you are using may require some identifying information in order to send the output to the proper address. The user filling out the form doesn't need to see this information, but it must be included.
A field labeled file allows a user to upload a file from his or her system to the server.
Coding of forms in HTML is really easy compared to laying them out in a way that makes it easy for readers to understand what you want them to do. Fortunately, because you can intersperse text, other HTML tags and the forms themselves, you have many tools at your disposal for designing a good form.
Remember that not all browser windows are as wide as yours. If your lines are too long (for example, if you put text and input field on the same line) the form may appear unpredictably and not be understandable. Use <br / > for controlled line breaks and <p></p> for spacing between sections of your form and/or text.
You can also put forms inside list coding and inside tables. Both of these are good ways to help arrange your requests for input. I have made up a sample forms page that illustrates each of the types of input and also uses various layout devices. Frames are required for viewing the page and coding side-by-side, but if you just want to look at the page, you can see the coding by viewing the source. This example also illustrates the use of the mailto action attribute in the <form> tag.
IMPORTANT NOTE: All of the instructions in this and my other tutorials apply to authoring for the Web at present (mid-2007) and will continue to be useful into the future. But to be sure you are using the latest standards, especially as we get further from 2007, you can always check with the good folks at W3Schools.