Usable forms

It crashes Explorer 5 Mac when you use the script too much (a few changes is OK).

Opera sends all form fields to the server, also those in the waiting room.
I have heard, but not tested, that Safari 1.1.1 does the same.

In quirks mode Opera cannot handle nested select boxes, though in strict mode it can.

Explorer 6 Windows hides this floating div as soon as you add or remove form fields.

The script does not work on <label> tags in all browsers. This is dependent on whether the click event of a form field fires when the user clicks on the label. I need to write a workaround for this, but don't have the time right now.

On this page I give the download link and some extra information on the Usable Forms script. This script is meant to show and hide form fields based on user actions. I explain this script in great detail in my Digital Web Magazine article Forms, usability and the W3C DOM.

Download

Download the script. Current version: 1.0 . For further instructions see my article.

Safari update: The 1.0 release supports this script also in Strict mode.

This is the only script on my site that contains a copyright notice, because it's more special and ground-breaking than any of my scripts. You may do whatever you like with it, as long as this copyright notice remains intact. If you extend the script, please also extend the notice to explain what you've done.

Example

The script adds and removes form fields based on user actions. Try the form below.

Name
Address
Country Other than The Netherlands
If not the Netherlands: Which other country?
Marital status Single
Married
Divorced
If Married: Marriage contract? Yes
If Divorced: Date of divorce
If Divorced: Type of divorce
If Very Messy: Gory details
Why do you fill in this form?
If Just a Feeling: Please describe this feeling in excessive detail.

Overview

The script works as follows:

  1. When initializing the form, the script searches for all TR's with a relation attribute.
  2. Every one of these TR's is placed in the "waiting room" outside the form and thus becomes invisible to the user. The script inserts a hidden marker TR with the same id value as the relation value of the removed TR. This marker is for returning the TR's to their correct places in the form later on.
  3. Then the script goes through all form fields. When it encounters a form field that is checked or selected and has a show attribute, the appropriate TR's are shown.
  4. Finally, the script registers an overall onclick event handler to the entire document.

Now the script waits for user input.

  1. If the user clicks anywhere on the page, the script checks if the target of this click event is a form field with a show attribute. If it isn't, nothing happens.
  2. If the user clicks on a form field with a show attribute, the script looks for TR's having the same value for their relation attribute. It gathers them and puts them back in the form, using the marker to determine the exact spot.
  3. If the form field is part of a group (radios or options) the script goes through all other fields in that group and hides the TR's related to them.
  4. If the script finds a value 'none' for the show attribute, it doesn't show any new TR's. It does hide the TR's related to the other form fields in the group, though.

Critique

A few WDF-DOM members gave some good feedback. There were two points of critique:

  1. It's better to move hidden TR's to a JavaScript array instead of putting them somewhere else in the HTML document. Having thought about it, I agree. The next version of the script will use a JS array for a waiting room, not an HTML construct.
    I'll need to do a major rewrite of the script to change this, though. Don't know when I'll have the time.
  2. Server side handling of the form becomes more difficult because the server side script cannot be certain which data it'll receive.
    Is this because of my script or because of assumptions server side programmers make? I'm not sure. There is no fundamental reason why a form handling script would not be able to handle my script. On the other hand, there certainly are some practical difficulties.
    One remark set me thinking: how about letting the server side script parse the actual HTML page to see what it can expect when the form is submitted? That might be a solution.