Creating Forms

There are lots of forms on web pages that don't work properly for one reason or another and even more which do not validate properly as HTML (which means that they potentially don't work properly in all browsers). In many cases it looks like whoever wrote the page has just thrown together a few tags to create something that looks a bit like a form without really understanding how to properly create a form.

To assist you in getting the forms in your web page to validate, be as semantic as possible, and as user friendly as possible, let's go through the steps required to create a form properly. The exact order that you create the parts of the form doesn't really matter but the following order ensures that you don't overlook anything.

The first thing you need is the form tag itself and the corresponding closing tag. As a minimum the form tag needs an action attribute that indicates the page or server side script that you want to run when the form is submitted and a method attribute to define how the values from the form are going to be passed. Perhaps the most useful of the optional attributes is to give the form an id so as to allow it to be easily styled from your stylesheet. Actually applying styles to the form so as to define how the form should look is something that you can do after you have created and tested the form itself. Any other attributes in the form tag generally means that you are using outdated processing as the previously mentioned two or three attributes should be all you need to get your form to look and function the way it is supposed to.

For your HTML to be valid, you can't place actual form fields directly inside the form tag. They need to be inside of a block level element that is itself inside the form. The most semantic choice of tag for this purpose is the fieldset tag but the div is a reasonable alternative if you don't want to use any of the other features associated with using a fieldset. While there are other block level tags that would validate, none of them is likely to be as semantically correct as one of these two will be. All of the content of your form needs to be wrapped in one of these tags but it is up to you whether you wrap the entire form content in the one tag or have several of these tags wrapping different parts of the form. You can even use fieldset tags around some parts of the form and div tags around other parts of the form or even nest fieldset tags inside one another.

Where you do use more than one div or fieldset around your form content the purpose of the tags should be to group the content into related sections - for example you might wrap all of the radio buttons in a group inside a fieldset so as to clearly define those buttons as a group, particularly if there is more than one group of radio buttons in the form.

The next thing that your form needs is a submit button of some sort. This and all of the other actual elements of the form need to be added inside of a fieldset or div wrapper that you have placed inside the form. There are three different ways to create a submit button. The most common is to use an input field with a type="submit" attribute and a value attribute to provide the text to display on the button. If you want to use an image as the submit button then you replace the type="submit" with type="image" and replace the value with src, width, and height attributes to define the image to use. The third way is to use a button tag with corresponding closing tag and to put a type="submit" attribute in the tag and HTML between the open and close tags to define the content of the button - this makes it easy to style the actual text that appears in the button. As with the form tag, using any other attributes on this tag generally means that you are using outdated processing as the attributes mentioned are all that you need with the possible exception of an id to allow the button to have specific styles applied.

If you wish to have multiple submit buttons to perform different processing using the same form then you will need to use either the first or third of the previously mentioned options and then add a name attribute to each to supply different values to be passed with the form that will identify which of the submit buttons was used to submit the form. If you are using a button tag then you will also need to add a value attribute to supply a value to be passed. Note that it is not possible to use images to do this as only the location within the image where the mouse pointer was located at the time of submitting the form will be passed if you put a name attribute on that tag and any value attribute will be ignored.

The final step in creating the HTML for the form is to add the actual form fields themselves. Each field in addition to the attributes needed to define what type of field it is and its default value will also need a name attribute to identify the field that submitted value should be loaded into on the server and an id attribute to attach the label that identifies what the field is for. With the exception of radio buttons and form fields that are to be loaded into arrays on the server you might consider using the same value for both the name and the id.

The text identifying what the field is for should be wrapped inside of a label tag and its corresponding closing tag. The label tag should have a for attribute specifying the id of the field that it is labelling. This not only clearly identifies which text is labelling which form field within your form but it also extends a lot of the functionality associated with the form fields to include their label. For example clicking on the label for an input field gives that input field the focus just as if you had clicked on the field itself and clicking on the label for a radio button selects that radio button. This makes your HTML form behave far more like the forms people see in the programs that they run on their own computer and also makes the form easier to use by giving them a much larger area in which to click in order to interact with a field.

While wrapping a label around both the text and the input field itself so as to do away with the need for the for attribute on the label and the id attribute on the field, it is not exactly a semantic way of writing the code as it implies that the form field itself is a part of the label. More importantly it is far easier to interact with the form from JavaScript when the form fields have an id.

With all of the actual HTML for the form in place and tested you can then move on to define how the form should look by adding entries into your stylesheet that will be applied to the form. You may need to update the HTML at this point in order to apply class attributes to some of the tags in your form so as to make it easier to style the form. As older browsers die out this should gradually become less necessary as more modern browsers support additional ways of referencing the component parts of a form to style them which would make identifying them with a class unnecessary.

The final step would be to attach JavaScript to the form in order to make the form more user friendly by identifying some of the input errors before the form is submitted or even making the form fully functional without even needing to send it to the server. Note that none of the JavaScript that you add should be essential for the form to work. Not everyone has JavaScript enabled and so the form should work without it. There should not be any need to alter the HTML in any way in order to attach the JavaScript since the form should already have sufficient ids defined in the form to allow the JavaScript to be attached to the appropriate form fields.

If you follow all of the above steps in defining your forms then you will always end up with forms that are valid, semantic, and user friendly.

Here's an example of a properly defined HTML form (from one of my loan calculators - note that the id is on the form tag and the classes attached to the various parts of the form allow the CSS to be attached that styles the form):

<form action="/scripts/loan.php" method="POST" id="loan">
<input type="hidden" name="ml" value="0">
<fieldset class="tc">
<div class="tm"><h3>Loan Principal Calculator</h3></div>
<div class="tm"><label for="loanInstalment" class="tl">Instalment</label>
<div class="tr"><input type="text" name="il" id="loanInstalment" size="10" value=""></div>
<div class="tm">
<label for="loanRate" class="tl">Nominal Annual Interest Rate</label>
<div class="tr"><input type="text" name="rl" id="loanRate" size="8" value=""> %</div>
<div class="tm">
<label for="loanTerm" class="tl">Term of Loan</label>
<div class="tr"><input type="text" name="tl" id="loanTerm" size="3" value=""> years</div>
<fieldset class="tm"><legend>Instalment Period</legend>
<ul class="tx"><li><input type="radio" id="ml1" name="ml" value="1"><label for="ml1">yearly</label></li>
<li><input type="radio" id="ml2" name="ml" value="2"><label for="ml2">six monthly</label></li>
<li><input type="radio" id="ml3" name="ml" value="3"><label for="ml3">four monthly</label></li>
<li><input type="radio" id="ml4" name="ml" value="4"><label for="ml4">quarterly</label></li>
<li><input type="radio" id="ml5" name="ml" value="6"><label for="ml5">bimonthly</label></li></ul>
<ul class="tr"><li><input type="radio" id="ml6" name="ml" value="12"><label for"ml6"="">monthly</label></li>
<li><input type="radio" id="ml7" name="ml" value="24"><label for="ml7">twice monthly</label></li>
<li><input type="radio" id="ml8" name="ml" value="26"><label for="ml8">fortnightly</label></li>
<li><input type="radio" id="ml9" name="ml" value="52"><label for="ml9">weekly</label></li>
<li><input type="radio" id="ml0" name="ml" value="365"><label for="ml0">daily</label></li></ul>
<div class="tm"><input type="submit" value="Calculate Principal"></div>
<fieldset class="tm">
<div id="loanPrincipal" class="tm"> </div>


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow