This document answers questions asked frequently by web authors. While its focus is on HTML-related questions, this FAQ also answers some questions related to CSS, HTTP, JavaScript, server configuration, etc.
This document is maintained by Darin McGrew <darin@htmlhelp.com> of the Web Design Group, and is posted regularly to the newsgroup comp.infosystems.www.authoring.html. It was last updated on April 26, 2007.
The basic syntax for a form is:
<FORM ACTION="[URL]">...</FORM>
When the form is submitted, the form data is sent to the URL specified
in the ACTION attribute.
This URL should refer to a server-side (e.g., CGI) program that will
process the form data.
The form itself should contain
<INPUT TYPE="submit" ...> element),
The only reliable mechanism for processing form submissions is with a server-side (e.g., CGI) program. To send form data to yourself via email, you should use a server-side program that processes the form submission and sends the data to your email address.
Some web service providers make standard form-to-email programs available to their customers. Check with your service provider for details.
If you can install CGI programs on your own server, see the answer to the previous question for a list of useful resources.
If you can't run CGI programs on your own server, you can use a remotely hosted form-to-email services. Note that the provider of a remotely hosted service will have access to any data submitted via the service.
Forms that use action="mailto:..." are unreliable.
According to
the HTML specifications,
form behavior is explicitly undefined for mailto URIs (or anything else
other than HTTP URIs).
They may work one way with one software configuration,
may work other ways in other software configurations,
and may fail completely in other software configurations.
Small forms are sometimes placed within a TD element within a table. This can be a useful for positioning a form relative to other content, but it doesn't help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire table must be within the form. You cannot start a form in one TH or TD element and end in another. You cannot place the form within the table without placing it inside a TH or TD element. You can put the table inside the form, and then use the table to position the INPUT, TEXTAREA, SELECT, and other form-related elements, as shown in the following example.
<form action="[URL]">
<table border="0">
<tr>
<th scope="row">
<label for="account">Account:</label>
</th>
<td>
<input type="text" name="account" id="account">
</td>
</tr>
<tr>
<th scope="row">
<label for="password">Password:</label>
</th>
<td>
<input type="password" name="password" id="password">
</td>
</tr>
<tr>
<td> </td>
<td><input type="submit" name="Log On"></td>
</tr>
</table>
</form>HTML has no mechanism to control this. However, with CSS, you can set the margin-bottom of the form to 0. For example:
<form style="margin-bottom:0;" action=...>
You can also use a CSS style sheet to affect all the forms on a page:
form { margin-bottom: 0 ; }
The short answer is that the form should just have one
<INPUT TYPE=TEXT> and no TEXTAREA, though
it can have other form elements like checkboxes and radio buttons.
You cannot do this with HTML. However, you can include a script after the form that sets the focus to the appropriate field, like this:
<form id="myform" name="myform" action=...>
<input type="text" id="myinput" name="myinput" ...>
</form>
<script type="text/javascript">
document.myform.myinput.focus();
</script> A similar approach uses <body onload=...> to set the
focus, but some browsers seem to process the ONLOAD event before the entire
document (i.e., the part with the form) has been loaded.
Rather than a normal submit button
(<input type="submit" ...>), you can use the
image input type (<input type="image" ...>).
The image input type specifies a graphical submit button that functions
like a server-side image map.
Unlike normal submit buttons (which return a name=value pair), the image input type returns the x-y coordinates of the location where the user clicked on the image. The browser returns the x-y coordinates as name.x=000 and name.y=000 pairs.
For compatability with various non-graphical browsing environments, the VALUE and ALT attributes should be set to the same value as the NAME attribute. For example:
<input type="image" name="Send" alt="Send" value="Send"
src="send-button.gif">
For the reset button, one could use
<button type="reset" ...>, JavaScript, and/or style
sheets, although none of these mechanisms work universally.
Yes. This is part of HTML 2.0 Forms support (some early browsers did not support it, but browser coverage is now excellent).
The submit buttons must have a NAME attribute. The optional VALUE attribute can be used to specify different text for the different submit buttons.
To determine which submit button was used, you need to use different values for the NAME and/or VALUE attributes. Browsers will send to the server the name=value pair of the submit button that was used. Here is an example:
<input type="submit" name="join" value="I want to join now">
<input type="submit" name="info" value="Please send full details">
Note that if you are using image submit buttons, you need to provide different NAME attributes for them too. Also, browser behavior can be inconsistent when the form is submitted without a submit button (e.g., by hitting ENTER).
If you're unsure what results you're going to get when you submit your form, TipJar has a standard script which you can use. Code this, for example (assuming method "post"):
<form method="post"
action="http://www.tipjar.com/cgi-bin/test">
and then go through the motions of submitting your form. The TipJar server decodes the form input, and displays the result to you.
No. A form must have exactly one action. However, the server-side (e.g., CGI) program that processes your form submissions can perform any number of tasks (e.g., updating a database, sending email, logging a transaction) in response to a single form submission.
Have the server-side (e.g., CGI) program that processes the form submission send an error message if the field is not filled in properly. Ideally, this error message should include a copy of the original form with the original (incomplete or incorrect) data filled in as the default values for the form fields. The Perl CGI.pm module provides helpful mechanisms for returning partially completed forms to the user.
In addition, you could use JavaScript in the form's ONSUBMIT attribute to check the form data. If JavaScript support is enabled, then the ONSUBMIT event handler can inform the user of the problem and return false to prevent the form from being submitted.
Note that the server-side program should not rely upon the checking done by the client-side script.
No. The server-side (e.g., CGI) program that processes the form submission must handle duplicate submissions gracefully.
You could generate the form with a server-side (e.g., CGI) program that adds a hidden field with a unique session ID. Then the server-side program that processes the form submission can check the session ID against a list of previously used session IDs. If the session ID has already been used, then an appropriate action can be taken (e.g., reject the submission, or update the previously submitted data).
Ultimately, your server-side program must be smart enough to handle resubmitted data. But you can avoid getting resubmitted data by not expiring the confirmation page from form submissions. Since you want to expire pages quickly when they have transient data, you might want to avoid putting transient data on the confirmation page. You could provide a link to a database query that returns transient data though.
These things are necessary for Web-based uploads:
<form method="post" enctype="multipart/form-data"
action="fup.cgi">
File to upload: <input type=file name=upfile><br>
Notes about the file: <input type=text name=note><br>
<input type=submit value=Press> to upload the file!
</form>
Not all browsers support form-based file upload, so try to give alternatives where possible.
The Perl CGI.pm module supports file upload. The most recent versions of the cgi-lib.pl library also support file upload. Also, if you need to do file upload in conjunction with form-to-email, the Perl package MIME::Lite handles email attachments.
There is no way to do this in HTML only; something else must process the form. JavaScript processing will work only for readers with JavaScript-enabled browsers. CGI and other server-side processing is reliable for human readers, but search engines have problems following any form-based navigation.
All rights reserved.