Internet Explorer As A Development Platform?
META tags: What they are and how they work
Stop! Is Your HTML Document Valid?
HTML #4 - Advanced Page Layout
You are here: irt.org | Articles | HTML | HTML #5 - Using feedback forms [ previous next ]
Published on: Sunday 4th October 1998 By: Michael Bednarek
Hello once again, and welcome to the final article in my HTML series. Over the past few months I've been teaching you the basics of HTML, including text, graphic, hyperlinks, music, tables and frames. With all this knowledge you can make some impressive web sites - the only thing left is a feedback form, so that your visitors can tell you just how good your site actually is. This is what I'll be focusing on in this final article.
You've probably come across feedback forms at some point on the Web. They look very similar to proper forms in the real world - sometimes you have to type in an answer, sometimes you have to tick a few boxes, etc. - but they're a lot more flexible and useful. You may wonder what their purpose is, when a link to an e-mail address is just as valid a way of getting people to contact you. Well, forms are good for spontaneity. If people have something on their mind when visiting your site, they're more likely to quickly fill in a form and send it than to bother spending the time to compose an e-mail.
Forms have other advantages too. With a form you can gather useful information about the sender, such as browser, IP address, host name, and referring URL, to help you analyse the visitors to your site.
Finally, forms don't have to be used for visitor feedback either. You often see buttons and drop down menus used as navigation systems in web sites, and the various elements of a form can be combined with script to provide powerful functionality.
But let's start at the very beginning - a very good place to start - with a look at....
As I've already mentioned, a form consists of a number of different elements, such as text boxes, menus, and buttons, which hold data values which you provide. Forms usually also have a Submit button. This button is used when the form has been filled in and is ready to be sent off. When the button is clicked, the browser goes through each of the elements in the form and notes down the name of the element (if any) and its current value.
What happens next depends on how the form is configured. Sometimes, the form is set to send these details to a certain e-mail address, by using the mailto: protocol which you met in Formatting text in HTML. Other times, the information is sent to a specific location, usually a server program such as a CGI script.
The recipient program will know what to do with the information it receives - it may store it in a log file, send it somewhere else, or display a dynamically generated page dependent on the data. It can receive this data in one of two methods: either GET or POST. If the GET method is used, the form data is combined into a string, and this string is added on to the end of the target location - for example:
http://www.site.com/cgi-bin/form.cgi?fname=Michael&lname=Bednarek&country=England
Here the CGI script has received form data including a first name ("Michael"), last name ("Bednarek") and country ("England").
The POST method groups the data together and sends it to the program by HTTP (HyperText Transfer Protocol), so the user can't see what data is being sent. This is the method used when sending data using mailto:. How do you know which method to use? The HTML 4.0 specification at W3C suggests that GET should be used if the form causes no side effects, and POST if it does. For example, submitting keywords for a search of a database would have no side effects, and so the GET method would be used. But submitting data which will be entered into a database, or which will be written to a log file, should be done with the POST method.
That's not all you have to worry about with forms - you need to make sure the data is sent in the correct way. When the form data is processed, it is encoded into a certain type. These types define the way the data is later read, and they are called MIME or content types. They have special codenames which are readable by browsers and other programs, to enable them to interpret the data correctly.
The default MIME-type for form submission is application/x-www-form-urlencoded. This MIME-type will take your text and will remove any spaces and punctuation, replacing them with special character codes (this allows it to be transmitted via HTTP). When the data is received, it is decoded by the CGI script into readable text.
There are two occasions when this MIME-type might be undesirable. When you are sending the form results to an email address using mailto:, you wouldn't want to receive a load of undecipherable garbage; you'd want to receive nice, understandable text. You'd have to specify that the form use the text/plain MIME-type.
Secondly, it may surprise you to know that files can be included with forms too. Now obviously, if you're sending a file to a server or another person, you don't want it to be converted into a weird load of text. You want it to keep its binary form. Therefore you use the multipart/form-data MIME type. This MIME type splits the form data into a number of separate parts, one for each form element, and then sends the parts, each encoded in their own different way.
You may wonder why on earth I just droned on with all that technical stuff for the last few paragraphs - you just want a simple, no-nonsense form, right? Well, the reason is that unless you're using your form for JavaScript, you'll need to know at least some of what I've just told you in order to write a correct FORM tag.
The <FORM> tag encloses all the elements of a feedback form. You can have as many different forms on a page as you want, and each form is enclosed by its own FORM tag. All the data from all the elements inside the FORM tag goes to the same place and is treated in the same way.
The FORM element has several attributes which you need to specify for each form that you create. First of all, the METHOD attribute, which (as you may have guessed) can be either GET or POST. Secondly, the ACTION attribute, which is the location of the URL or e-mail address which will receive the form. There's also the ENCTYPE attribute for the MIME-type of the form data, the NAME attribute to identify the form in JavaScript (you should use the ID attribute for HTML 4.0), and the TARGET attribute, to define in which frame the form results will appear.
For example, here's a line I might use to send a form directly to my e-mail address:
<FORM METHOD=POST ACTION="mailto:michael@irt.org" ENCTYPE="text/plain">
One problem with this is that the use of the mailto: protocol in a form is not supported in Internet Explorer except in version 4 or higher. This is why you see a lot of CGI scripts around which will receive the form data and send it on to an e-mail address instead (this method is supported by all browsers). Let's take another example; suppose I wanted to use such a script and have the results/acknowledgement page appear in the "results" frame:
<FORM METHOD=POST ACTION="/cgi-bin/formmail.cgi" TARGET="results">
A form in HTML consists of one or more elements, or controls, which hold data values. We'll now take a look at each one in detail.
The textbox is the most common form element, and is used for text values such as a person's name, address, telephone number, product type, product code, and anything else you can think of. It is created with the INPUT tag, which is also used for many of the other form elements. You can include its SIZE, NAME, VALUE and the maximum number of characters (letters or numbers) which will fit in the box (MAXLENGTH).
For example, suppose I wanted a textbox to hold a person's web site address. This textbox would need to be pretty large, say about 40 characters, because URLs are long (although the contents of the box can scroll). I would call this textbox "site_url", so that a meaningful name is given when I view the form results. Finally, I would also like the starting value to be "http://www.", because most URLs start this way. I'd use the line below:
<INPUT TYPE=TEXT SIZE=40 NAME="site_url" VALUE="http://www.">
Which would produce:
The password box is just like a textbox, but when you type something in it, all you see on screen is a series of asterisks (*). Really this control offers little protection other than from anyone who might happen to be peeking over your shoulder at the time; the value of the box when the form is submitted is not hidden or encrypted in any way.
To create a password box, you use exactly the same procedure as a normal text box, but instead of TYPE=TEXT you use TYPE=PASSWORD. For example:
<INPUT TYPE=PASSWORD SIZE=20 NAME="unlock_code">
Which comes up as:
A text area is similar to a textbox, except it is multi-line and can scroll downwards. It's therefore suitable for large amounts of text, such as the body of a letter, or comments for the guestbook. A text area is defined in columns (i.e. number of characters on a line) and rows (number of lines). The area is scrollable so there's no limit to the amount of information you can put in, just the amount you can see.
You create a text area with the TEXTAREA tag, which is opened and then closed. Anything inside the tag shows up inside the textarea already. The tag has NAME, ROWS and COLS attributes, and the READONLY attribute (HTML 4.0) which specifies if you can change what's in the area (useful for displaying license agreements and other such things).
It also has the WRAP attribute, which is not official HTML but useful nonetheless. The WRAP attribute controls how the text is sent to the form when submitted. Setting WRAP to OFF will obviously turn it off completely. Setting it to VIRTUAL will make the text appear to be wrapped, but it will be sent to the server unwrapped. Setting it to PHYSICAL will introduce wrapping both onscreen and in the form submission results.
For example, the following line will create a TEXTAREA with 6 lines, each 25 characters long. It will be read-only and will have text in it already.
<TEXTAREA NAME="mytext" ROWS="6" COLS="25" READONLY WRAP="VIRTUAL"> Hi everyone, this is some text in a text area box. Try to delete it - in supported browsers, you can't. </TEXTAREA>
Note: NN4 does not yet provide complete support for HTML 4.0, therefore the READONLY attribute has no effect.
Here's an example:
The real-life equivalent of the checkbox are those boxes that you find in surveys with questions such as "Which of the following do you enjoy doing? Tick all that apply". In HTML forms, each checkbox, though it may be a different option of the same question, is actually a separate control. The value it returns is either true or false, depending on whether the user has clicked on it or not.
Checkboxes, like the textbox and many other form controls, are created with the INPUT tag. For each one, you need to specify a unique NAME. The CHECKED attribute (it's either there or it's not) controls whether the checkbox first appeared checked or not.
So, to take our real-life example further, here's the code we would use:
Which of the following do you enjoy doing? Tick all that apply.<BR> <INPUT TYPE=CHECKBOX NAME="fishing">Fishing<BR> <INPUT TYPE=CHECKBOX NAME="reading">Reading<BR> <INPUT TYPE=CHECKBOX NAME="dancing">Dancing<BR> <INPUT TYPE=CHECKBOX NAME="sports" CHECKED>Sports
Remember that the above code would need to go inside a FORM tag. When the form is submitted, the results would include the names of the boxes which were checked. Notice that the "sports" checkbox is checked by default. Here's what it looks like:
Radio buttons are similar to checkboxes except that only one button in a group can be selected at any one time. This is useful for questions which can have only one answer, such as "What country are you from?", "What do you think of our site?", and "Are you over 21 years of age?".
The construction of a set of radio buttons is a little different from checkboxes, though as you would expect, you once again use the INPUT tag. This time, all radio buttons in a group must have the same NAME, and it is their VALUE that distinguishes them from each other. For example:
What do you think of our site?<BR> <INPUT TYPE=RADIO NAME="site_opinion" VALUE="great" CHECKED> I thought it was amazing<BR> <INPUT TYPE=RADIO NAME="site_opinion" VALUE="average"> It was distinctly mediocre<BR> <INPUT TYPE=RADIO NAME="site_opinion" VALUE="ohdear"> This is the worst site I've ever seen in my life, thanks.<BR>
Once again you can see that the CHECKED attribute applies, to show the default selection. And here's what it looks like:
Menus are useful for when you need the user to select one or more options from a large selection. The menu is usually rendered as either a list box or a drop-down menu, so hundreds of different options can be included if desired - as much as the user's memory can hold. Typical uses for this type of control include "What country are you from?", "Which US state are you in?", as well as a navigational aid in conjunction with JavaScript or CGI - just take a look at the top of this page for an example.
A menu is created with the SELECT tag. The SELECT tag has three attributes that you're interested in - the ubiquitous NAME attribute and the MULTIPLE and SIZE attributes. The latter controls how many rows of the menu are visible: omit it and the menu is usually show as a drop down list; make it larger than one and it becomes a scrolling list box. The MULTIPLE attribute (either present or it's not) controls whether the user can select more than one option.
Within the SELECT tag, each option available to the user is defined with the OPTION tag. The OPTION tag has two main attributes - VALUE and SELECTED. The VALUE attribute is what will be submitted to the form if this option is selected in the menu. The SELECTED attribute determines whether this option is initially selected or not. Whatever comes after the OPTION tag is the text that is shown to the user in the menu; you don't actually have to close the tag, but you can if you want to.
Now that you've hopefully absorbed all of this, let's take a look at two examples of menus. The first one is a scrolling list box where you can have multiple selections:
<SELECT NAME="actors" MULTIPLE SIZE="4">
<OPTION VALUE="arnie">Arnold Schwarzennegger
<OPTION VALUE="stallone">Sylvester Stallone
<OPTION VALUE="vandamme">Jean Claude Van Damme
<OPTION VALUE="washington">Denzel Washington
<OPTION VALUE="willis">Bruce Willis
<OPTION VALUE="moore">Demi Moore
<OPTION VALUE="stone">Sharon Stone
<OPTION VALUE="anderson">Gillian Anderson
<OPTION VALUE="winslet">Kate Winslet
<OPTION VALUE="streep">Meryl Streep
</SELECT>Next we have a drop down menu where only one selection is possible:
<SELECT NAME="film">
<OPTION VALUE="terminator2">Terminator 2
<OPTION VALUE="crow">The Crow
<OPTION VALUE="fallen">Fallen
<OPTION VALUE="godzilla">Godzilla
<OPTION VALUE="lostspace">Lost in Space
<OPTION VALUE="xfiles">The X-Files
</SELECT>Here's what they both look like:
The HTML 4.0 specification increases the functionality of menus, so that they can be rendered as cascading or hierarchical menus. In order to do this, it introduces the OPTGROUP element. This simply groups together a number of different OPTION tags under a common name. In a cascading menu, the option you select would be the OPTGROUP name, and this would open up to reveal all the OPTIONs in that particular group.
The OPTGROUP element has only one attribute, LABEL, which specifies the name of the group. Here's an example use of the OPTGROUP element:
<SELECT NAME="films2">
<OPTGROUP LABEL="Comedy">
<OPTION VALUE="dumber">Dumb and Dumber
<OPTION VALUE="4rooms">Four Rooms
</OPTGROUP>
<OPTGROUP LABEL="Horror">
<OPTION VALUE="elmstreet">Nightmare on Elm Street
<OPTION VALUE="scream">Scream
</OPTGROUP>
<OPTGROUP LABEL="Romance">
<OPTION VALUE="frenchkiss">French Kiss
<OPTION VALUE="sleeping">While you were sleeping
</OPTGROUP>
</SELECT>As there isn't (at the time of writing) a browser that supports OPTGROUP then the following example defaults to a normal drop down menu, if you are lucky enough to be viewing this article on a browser that has added this function then you should see it in all its glory:
When the next generation browsers are released however, and as people get to grips with the new features of HTML 4.0, you can expect it to become more and more common.
As I mentioned at the beginning of this article, it's actually possible to include a file with your form submission. This file is uploaded to the server and then the recipient program does something with it, perhaps storing it in a certain place or sending it somewhere. In order to receive files from a form, you must make sure your form is encoded in the correct way (see How forms work). To enable the user to select the file, you then need to add a file select control to the form. This is once again accomplished with the INPUT tag.
This time it's really simple:
<INPUT TYPE=FILE SIZE=35 NAME="myfile">
This will show up differently in different browsers and platforms, but basically it comes up as a textbox (size 35), with a Browse button next to it. Clicking on this button will invoke the operating system's file selector (such as the Windows File Open dialog box), allowing you to pinpoint the location of the file you want. For example:
There may be occasions where you want certain information to be sent with the form, but you don't want this information to be visible to the user. This is where hidden controls come in. Hidden controls don't show up at all on the form, but when the form is submitted they do produce a name and a value. This value can also be changed, using JavaScript.
Let's have a look at how a hidden control is created. As you would by now expect, hidden controls are made with the INPUT tag. Very simply:
<INPUT TYPE=HIDDEN NAME="hidden1" VALUE="myvalue">
Now, let's take a closer look at why you'd want to use these hidden controls. The most common reason is for a little "market research" into your visitors. For example, if you have the same form on several pages of your site, you can set a hidden control with the value being the title of that page - then you can see from which page the user sent the form.
Other things you can look at with JavaScript (and now the Document Object Model in DHTML) include the visitor's browser type and version, their screen resolution, and the referring page (the page with the link that the user clicked on to get to yours, if any). For more information on this, check out Form Tricks.
Hidden controls are also sometimes used to provide extra parameters or values to specially configured CGI scripts, to make them act in a certain way. For example, a form-to-email script might look at a hidden control in order to find out which e-mail address it should send the form to, and which page it should display after the form is submitted. This may not be the best way to do things, however, because of potential security problems.
Buttons are arguably the most important components in a form. They are extremely versatile and can be configured for many different functions. First and foremost, you normally click on a button in order to submit the form which you just filled out to the server. A button is also sometimes provided to clear your form if you've made a mistake. Forms are heavily connected with JavaScript, so a button is very often given some JavaScript code which executes when it is clicked.
Buttons can now come in many different shapes and sizes. There are different commands for each type of button, so let's look at the most common first - the Submit button. Just for a change, this button is created with the INPUT tag:
<INPUT TYPE=SUBMIT VALUE="Send the form">
This button will automatically submit the form to the program specified in the ACTION attribute of the FORM tag. If you omit the VALUE attribute, the button will show "Submit Query" or something similar.
If you have a large form, it's sometimes useful to let the user clear all of what they've written and start again. You can achieve this with a Reset button - the line is the same as a submit button, except that the INPUT TYPE=RESET.
Bog-standard buttons which are used in conjunction with script are created in the same way, but the INPUT TYPE=BUTTON.
Buttons in HTML 4.0 can now look more interesting than a boring grey box with black text on it. This is thanks to the introduction of the BUTTON element. There are two advantages to this. Firstly, you can now include the BUTTON tag in your style sheets in order to make your buttons look more attractive - for example, a blue background and yellow, bold text with a large font size.
Secondly, you can include content inside your BUTTON element. For example, you can include some formatted text to be displayed, and then a graphic too.
Below is an example of the BUTTON element in use. It has only one attribute, the TYPE attribute, which can be set to button, submit or reset depending on the functionality you want it to have.
<BUTTON TYPE=BUTTON>
<FONT FACE="Arial">
<B>Send</B>
<CENTER><IMG SRC="mail.gif" ALT="Send Mail" BORDER=0></CENTER>
<B>Mail</B>
</FONT>
</BUTTON>The above code has specified that the button text be Arial in bold (you could - and should - use CSS to achieve this). We have the word "Send", then an image centred in the button, and then the word "Mail". Since Internet Explorer 4 is the only browser to support this element at the time of writing, I've given you a little picture so you can see what it should look like:
Lesser browsers can still content themselves with using an image as a form button, thanks to the INPUT tag again. Using INPUT TYPE=IMAGE will create a Submit button based on the image you specify. This is done with the usual SRC attribute. You can also add the ALT attribute for a description and the USEMAP attribute to make the button into an image map. A good use of this might be a photo of several different people in a company, and the user clicks on a person in the photo to send the form's contents to that person.
We've already discussed certain form tags and attributes which are HTML 4.0 specific such as the BUTTON element and the READONLY attribute. HTML 4.0 introduces a couple of other innovations into forms in order to make them more user friendly - the FIELDSET and LEGEND elements.
Fieldsets allow you to group sections of related form controls together. For example, you could split a form into sections by subject. This would allow you to apply a different style to each fieldset in CSS, giving you greater power over the appearance of your form. Fieldsets can also have a legend to clarify what the group is called.
Fieldsets and legends are very simple to implement. You have one FIELDSET tag per group, inside the FORM tag, and inside this FIELDSET you put all the form controls which belong to that group, as well as the LEGEND tag. For example, a form for entering information into some sort of company database:
<FORM ACTION="mailto:person@domain.com" METHOD=POST>
<FIELDSET>
<LEGEND>Personal Details</LEGEND>
Name.....
E-mail.....
Country.....
</FIELDSET>
<FIELDSET>
<LEGEND>Employment details</LEGEND>
Position.....
Salary....
Supervisor....
</FIELDSET>
<FIELDSET>
<LEGEND>Company car details</LEGEND>
Make......
Model.....
Registration.....
Value....
</FIELDSET>
</FORM>This article has hopefully shown you how you can create user friendly and effective forms which will allow you to give your site extra functionality, whether it's by a JavaScript navigation technique or simply a feedback form so that your visitors can tell you what they really think.
As with most of the other articles in this series, I haven't covered every single possible element or attribute available to you, only the ones which I think are most useful to someone who is just starting out. I've also tried to include new (and mostly unsupported) HTML 4.0 elements in the articles, as well as describing the non-standard but useful attributes and elements which are proprietary Netscape or Microsoft additions.
If you have any questions about HTML or anything I've mentioned in the series, please mail me at michael@irt.org or alternatively check out the HTML FAQ to see if your question has already been asked. That's it for now - I hope you've enjoyed reading the series.
Internet Explorer As A Development Platform?
META tags: What they are and how they work
Stop! Is Your HTML Document Valid?
HTML #4 - Advanced Page Layout
HTML #3 - Making your Web pages more exciting