Working Smart with Forms

[ LiB ]

Forms aren't glamorous, but there are plenty of ways to make them look and function at their best. Dreamweaver can help you make your forms accessible to all visitors , to look their best, thanks to CSS formatting, and to be more interactive with the addition of Dreamweaver behaviors.

Making Your Forms Accessible

Because the whole purpose of forms is to be accessed and interacted with, form accessibility is a big issue. If a user can't use the mouse, how can he select a form field to type information into? If he can't see your page layout, how can he tell which form field is for the username and which is for the email address? Consequently, various rules, guidelines, and options apply to making acceptably accessible forms.

According to Section 508, §1194.22(n):

When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

That sounds like a lot! Luckily, browsers and operating systems take care of some of this for you, such as making it easy to activate form fields for the mobility-impaired. And the HTML specifications provide several mechanisms (some more well supported than others) for helping:

Labeling Even a user who can't see your form's layout should be able to tell without a doubt what each text field, check box, or other element is for. To accomplish this, every form element should include a label tag containing a text label that explains what information this element collects (username, password, phone number, favorite color , and so on).
Tab indexing A user who can't use a mouse should be able to use the Tab key to activate all form elements in order. The browser should allow this automatically (at least, on Windows or Mac OS X), but you can help users by adding a tabindex attribute to at least the first form element and optionally to all form elements. tabindex takes a number as its value, indicating the order in which elements can be tabbed through. So, the first element in the form should have a tabindex of 1 , the second element should a tabindex of 2 , and so forth.
Access keys Ideally, a user who can't use a mouse should be able to enter a key command that will activate a particular form field. For instance, type F to activate the First Name field. This bit of accessibility is not well-supported in browsers, however, and can conflict with OS-level shortcut keys, so it is not often used.

Using these guidelines, the basic code for an accessible form might look like this:

 <form name="theForm">  <label for="username">  User Name:</label>   <input type="text" name="username" id="username"  tabindex="1"    accesskey="n">   <label for="pword">  Password:</label>   <input type="password" name="pword" id="pword"  tabindex="2"    accesskey="p"  >   <input type="submit" name="submit" id="submit"  label="Submit"    tabindex="3"  > </form>

In this example, each item has a tabindex . Each item except the Submit button has a label and accesskey attribute. (The Submit button needs no accesskey: It is always accessed by pressing Return and needs no text label because it contains its own internal label attribute.) The form would also be acceptably accessible without the accesskey attributes.

Labels can be coded implicitlywrapped around the form element being labeled:

 <label>User Name   <input type="text" name="username" ... > </label>

Or, they can be coded explicitlyplaced next to the form element:

 <label for="username">User Name</label>   <input type="text name="username" ... >

According to the U.S. Access Board (www.access-board.gov), explicit labels are more reliable. They also allow for more design freedom.

Before the Fact: Set Accessibility Options

Before you create your form, make sure you have accessibility options for Forms turned on (Edit > Preferences/Accessibility). When this is enabled, the next time you use the Insert bar or menu to create a form element, you'll be presented with a dialog box letting you assign label , tabindex , and accesskey attributes (see Figure 9.9). Note that the same dialog box appears regardless of whether you're inserting a Submit button, a textarea , or another form element. It's up to you to know, for instance, that a Submit button can do without explicit labeling. The form object itself doesn't call up an accessibility dialog box because no special treatment is necessary for form tags.

Figure 9.9. The InputTag Accessibility Attributes dialog box in action.

The accessibility dialog box gives you choices for how your labels are coded and how they appear. To create explicit labels (coded separately from the form element rather than wrapped around it), choose Attach Label Tag Using for Attribute. To create implicit labels, choose Wrap with Label Tag. Whichever option you choose, use the Position choices to specify where the label should appear in relation to the form element (before or after). As mentioned earlier, explicit labels are more flexible and reliable. Implicit labels are easier to manage, however, because there is no for attribute to keep track of and no chance that the label and its related form element will become separated.

Remember that the text in the label tag will display in the browser window as regular text. So, when laying out your form, don't enter the text separately if you're going to use the accessibility dialog box to generate a label.

Working with tabindex and accesskey

To add or edit either the tabindex or accesskey attributes for an already existing form element, use the Edit Tag command (Style Sheet/Accessibility category) or Tag Inspector (see Figure 9.10). Neither of these attributes appears in the Property Inspector, but they are available in the Tag Inspector's CSS/Accessibility category.

Figure 9.10. Setting tabindex and accesskey in the Edit Tag dialog box and Tag Inspector.

Forget About accesskey

The smart money says, don't bother with accesskey unless you have a really good reason to do so. It's not well-supported, and it can actually cause conflicts with the user's operating system.

Apply tabindex Only as Needed

The tabindex attribute can be applied to other page elements besides form elements (the object and a tags, for instance), to allow users to skip directly to important page content. If the form is an important part of your page, however, you probably want users to be able to tab directly there, so don't clutter the page with other tabindex attributes. Not every form element needs to have a tabindex because after the user has activated the first field, built-in browser/OS tabbing features will take the user to additional fields. However, if you want to control tabbing order ( especially if you want to override browser/OS defaults), you can apply the attribute to all elements.

Use Nonconsecutive tabindex Values

Note that tabindex values don't have to be consecutive. If your first field has a tabindex of 10 and the second has a tabindex of 300 , the tabbing order will still go from a smaller to a larger number. You can use this to your advantage! If you think there's any chance you might be coming back later to add more form fields to the beginning or middle of your form, don't assign consecutive tabindex values to every field in the form. For instance, what if you have 20 fields and want to add a new field or two between the address ( tabindex=3 ) and phone number ( tabindex=4 )? You'll have to renumber almost every field in the form. Either don't assign tabindex to all form fields, or give the address field a number such as 10 and the phone number a higher number, such as 15 or 20 .

Working with Labels

Labels are different from tabindex and accesskey because they're coded as separate tags rather than attributes of the form element tag. They also create visible elements on the page.

If you've created form elements without labels, using regular text to identify them, you can easily convert that text into a label. Just select it and, in the Insert bar (Forms category), choose the Label object (see Figure 9.11). This wraps a label tag around your selected text. Because labels display in Code view, it also activates Code view so you can see the code being added. Note that the tag is entered without a for attribute, so it's not connected with any form field. You'll have to enter the for attribute in Code view or in the Tag Inspector.

Figure 9.11. Using the Label object to turn existing text into a form label.

Labels display in Design view as regular text, with no visual indicator that they're labels. If the insertion point is inside a label, though, the Tag Selector will display the label tag in its hierarchy. The Property Inspector doesn't recognize labels, so use the Tag Inspector to edit label properties such as the all-important for attribute.

Exercise 9.1. Create an Accessible Form

In this exercise, you'll create a form that uses various types of form elements. Figure 9.12 shows the finished page you're aiming for. Before you start, download the chapter_09 folder from the book's website at www.peachpit.com to your hard drive and define a site called Chapter 9, using that as the root folder.

Figure 9.12. The finished Supersite Evaluation form.

In the chapter_09 folder, open evalform.html . This page contains a main layout table holding a navigation bar across the top and a nested table to contain the form. Open the CSS Styles panel, and you'll see that several styles have already been defined in an external style sheet attached to this document. If you switch to Code view and examine the head of the document, you'll see that the style sheet has been attached using the import directive. These style sheets won't be recognized by Netscape 4, so you don't need to worry that your CSS formatting will render the form inoperative.
This will be an accessible form, so start by turning on Dreamweaver's accessibility features. Open the Preferences dialog box (Edit > Preferences), and in the Accessibility category, enable accessibility options for form elements.
The form tag needs to surround the table. Select the nested table (it shows up in the Tag Selector as table.formtable) and choose Edit > Cut. Then, with the insertion point still where the table used to be, insert a Form object from the Insert bar. Make sure invisible elements are showing (View > Visual Aids > Invisible Elements) so you can see its red outline. With the form still selected, in the Property Inspector, change its name to evalForm. Leave the other form properties alone for now.

Place the insertion point inside the form and choose Edit > Paste to put the layout table back in place. (Normally, when you're working, it's best to create the form object first, but it's nice to know how to add a form after the fact, for those times when you forget!)
The first row needs a text field and a label. Place the insertion point in the first cell and insert a text field. When the Input Accessibility dialog box appears, set the label to Your Name:, and choose to attach the label tag using the for attribute. For Position, choose Before Form Item. Leave tabindex and accesskey empty for now. Figure 9.13 shows what the dialog box should look like.

Figure 9.13. The Accessibility Options dialog box for the first text field in the Supersite form.

This inserts the label and text field both in the first cell, which you don't want. Deselect both items and then drag the form field into the second table cell.

You also need to give the text field a good name. Select it and, in the Property Inspector, set its name to fullname . When you've done that, select the text label and use the Tag Inspector to make sure the for attribute also says fullname (see Figure 9.14). (If it doesn't match, it's worse than useless!)

Figure 9.14. Make sure the text field's label matches the text field's name.
Repeat this procedure to create the second row of the table, which should contain a text field named email, with the label Your Email:.
For the next row, insert a List/Menu object. When the accessibility dialog box appears, choose User Level: for the label. Use the same technique to move the form field to a separate cell. Name the select element userlevel , and make sure the label is updated as well.

In the Property Inspector, click the List Values button to open the list values dialog box. Set the list values to the following:
(Select One)
Novice

Intermediate

Advanced

Power User
novice

intermediate

advanced

power
When you're done, click OK to close the dialog box and, in the Property Inspector, set Select One to be the default selected option. Figure 9.15 shows this happening.

Figure 9.15. Setting the list values for the userlevel drop-down menu.
The next table row contains a set of check boxes. The text in the left cell is not a label for any one element, so just type Software: into the table cell.

In the right cell of this row, insert a check box. Label it Dreamweaver and name it dw . For the checked value, enter DW and leave the initial state as unchecked. You need to add a line break after this element. Do it this way: Place the insertion point within the Dreamweaver label, use the Tag Selector to select the label tag that surrounds it, and press the right arrow key to move the insertion point after the label. Then press Shift+Return to create a soft return ( br tag). Insert another check box, labeled Fireworks and named fw , with check value FW and initial state unchecked. Repeat this procedure to create two more check boxes: one labeled Flash and named fla , with a checked value of FLA, and one labeled All of the Above and named all , with a checked value of ALL. Every check box should have an initial state of unchecked.
In the next row, there's a radio group . In the left cell, type in How Do You Like This Site? In the right cell, insert a radio group. This inserts as many radio buttons as you like. When the dialog box opens, name the group eval and create the following radio buttons :
Love It

Like It

So-So

Hate It
4

3

2

1
Set the list to be separated by line breaks. Figure 9.16 shows what the dialog box should look like when you're done. Click OK to close the dialog box.

Figure 9.16. Creating the eval radio button group for the Supersite form.

Select the Love It radio button and, using the Property Inspector, set it to be selected by default. (If users are too busy to fill out this part of the form, assume that they loved the site!) Check out the code for these buttons, and you'll see that they've been added with implicit labeling; the input tag is nested within the label. Explicit labeling is recommended, but implicit labeling has the advantage that you don't have to keep track of the for attribute.
In the last row, insert two buttons in the right cell. For each, set the labeling to no label tag; you don't want your buttons to have text labels sitting next to them because they have their own labels on them.

When both buttons are inserted, select the left one. You'll see that it's automatically a Submit button, but you can make it a Reset button. Choose Reset from the Action options in the Property Inspector. This automatically changes the button's label as well as its type. Its name becomes submit2. Change it to Reset.

Formatting Forms

With forms more than any other type of page content, you're at the mercy of the browser for what things will look like. Text fields, drop-down menus , check boxeseach browser and platform determines how these will appear. At the same time, it's crucial that your forms look tidy and inviting so that users will want to fill them out and will find them intuitive. The two main weapons in your form-formatting arsenal are tables and CSS. You also have the choice of substituting images for Submit and Reset buttons.

Form Layout with Tables

Tables help keep page elements aligned and organized. Organization is especially important when it comes to forms. Many designers organize forms in tables with one row per line of form elements, and optionally a separate column for labels, as is shown in Figure 9.17. Cell padding (applied via the Property Inspector or specified in a CSS style) or gutter cells can be used to separate the form elements from each other.

Figure 9.17. Using a table to control form layout.

For more on tables and layout, and their related accessibility issues, see the sections "Using Tables for Page Layout" and "Making Your Tables Accessible" in Chapter 8, "Building Tables."

Remember as you're doing this, however, that the form still needs to linearize well, or it won't be accessible. Screen readers read tables from left to right and top to bottom, so keep labels and form elements next to each other in the same row rather than putting the label on one row and its associated form element on the row below.

If you're using Dreamweaver's accessibility options to create your form labels and you want to put the form in a table in which labels and form elements are spread across different cells (as shown in Figure 9.1), be sure to use the Attach Label Using for Attribute option. This inserts the label and form element as separate tags. Dreamweaver inserts them both into the same table cell, but you can select either and drag it to another cell when it's in place.

Form Formatting with CSS

One of the frustrating aspects of designing HTML forms has always been how little control you have over their appearance. With CSS, things are looking up. By redefining form and form element tags and applying custom classes, you can add borders and backgrounds, determine sizes, and more. As usual with CSS, results aren't equally well supported across all browsers and for all form elements, so some experimentation and previewing is in order. But you can still do some nice things with your forms' appearance for most visitors (see Figure 9.18).

Figure 9.18. A form customized with CSS, as it appears in Internet Explorer 5, Netscape 6, Opera 5, and Safari 1.

With its limited support of CSS, Netscape 4 offers a particular challenge when it comes to form design. Not all styles display properly. But much more important, in some cases text fields can become nonfunctional, no longer accepting input. Obviously, this is unacceptable. A workaround is to create a style sheet that Netscape 4 won't see, using the import directive . See the section "Using Linked and Imported Style Sheets to Create a Netscape 4Friendly Site," in Chapter 11, "Using Cascading Style Sheets," for full details.

Text boxes Text fields and text areas can benefit from having borders and backgrounds applied, type properties specified for their input, and width controlled (use absolute sizes only).
Buttons You can use borders and backgrounds to control the appearance of buttons such as Submit and Reset. Width and height can also be used to control size (use absolute sizes only), although be careful that text display isn't chopped off.
List/menus Use borders, backgrounds, and type properties to control drop-down menus and lists in forms. You can also assign width (absolute sizes only), but be careful not to truncate text display.
Radio buttons/check boxes Not much can be done with these elements. Backgrounds and borders can be applied, but the effect isn't very nice.
Labels If you're using the label tag for all text labeling of form elements (and you should be, for accessibility!), you can use any CSS formatting that you would apply to any text elements on a page.

When designing style sheets for your form elements, it's better to apply custom classes and contextual selectors than to redefine tags. Different form elements use different tags, so it's easier to apply one class to input , select , and textarea tags than to redefine all three. The input tag, in particular, is used for so many different kinds of form elements (text fields, radio buttons, check boxes, buttons) that redefining this tag to suit each kind of element at once is difficult. Borders and backgrounds, for instance, work on text fields and buttons but don't apply nicely to radio buttons and check boxes.

Just because it's possible doesn't mean that it's always a good thing to do it. Don't forget that the primary purpose of forms is to be useful and easy to fill out. Colored backgrounds and other odd effects can interfere with that.

Using Images as Buttons

If you don't like the way the browser displays your Submit and Reset buttons, and if CSS doesn't give you enough options, you can always use image buttons instead (see Figure 9.19). To do this in Dreamweaver, use the Image Field object. When you choose this object, Dreamweaver presents you with a standard Select File dialog box to choose a GIF or JPEG image. But the image is inserted into your form as an input tag, with code like this:

Figure 9.19. A form with images substituted for the Submit button.

 <input type="image" name="imageField" border="0" src=  "myCloseButton.gif">

If you have accessibility options for form elements turned on, the standard Input Accessibility Options dialog box appears. As with regular buttons, you don't have to supply a label because the button will be its own label. But be sure to supply alt text for your image button, as you would with any image. When the image button is selected, the Image Field Property Inspector appears (see Figure 9.20).

Figure 9.20. The Image Field Property Inspector.

Exercise 9.2. Dress Up a Form with CSS Formatting

In this exercise, you'll format the form created in the previous exercise using CSS styles to control form elements' appearance.

Open evalform.html from the chapter_9 folder. It already has CSS styles governing text formatting. You'll be adding styles to govern form elements.
In the CSS Styles panel, click the New Style button. When the New Style dialog box opens, choose to create a custom class called .fieldborder , to be defined in the formstyles.css external document. Click OK to open the CSS Style Definition dialog box.

Go to the Border category. Leave Same for All Options selected and choose to create a solid 1-pixel black border. Click OK to close the dialog box.
Select the first text field and, using the Property Inspector's Class drop-down menu, assign the fieldborder class. Repeat this procedure for the second text field, the list/menu, and the Reset and Submit buttons.
Preview the results in as many browsers as you can to see how the formatting is supported.

The Ins and Outs of Form Processing

Forms collect information and pass it along for processing. That's the mysterious "back end" of web development that front-end designers usually know nothing about. But it's important, even for front-end folks, to get a sense of how everything fits together and to build better and more efficient forms.

Understanding the action Attribute

It all starts with that age-old question: What happens to forms when they're submitted? When a user presses the Submit button, the browser looks in the form tag for an action attribute. The action attribute holds the address of a receiving file that can presumably do something to process the form's input, like this:

 <form name="theForm" action="http://www.mysite.com/cgi-bin/  myscript.cgi" method="GET">

The browser sends that information to that receiving file's address using one of two methods :

With the GET method, the browser adds the information to the end of the receiving file's address as URL parameters, like this:
```
 http://www.mysite.com/cgi-bin/myscript.cgi?fname=Fred&lname=  Smith&favcolor=blue 
```
With the POST method, the browser sends the information as a separate packet of information

The POST method is more secure and can transmit larger amounts of data. GET is often used by search engines and for other nonsecure purposes.

Even though the form is usually submitted to a script file, it doesn't have to be. It can be submitted to any file. A form tag like this

 <form name="myForm" action="thankyou.html" method="get">

will send the information to a "thank you" page, and because that's a regular HTML page, it will display in the browser window. The "thank you" page might contain JavaScript for processing the information, or it might just ignore the information and display as any normal web page would.

A form tag like this

 <form name="myForm" action="mailto:laura@rocketlaura.com">

will send the form's information to an email address, which will cause the user's email program to send the named recipient a message containing all of the form data.

The mailto solution is very easy to implement but is very limited. If a user is on a machine that doesn't have a default email client installed (at the library or a cybercafe, for instance), the form will not send, but it will also not alert the user that there's a problem. Internet Explorer displays a security warning when the user submits the form, alerting the user that the sub-mission method is open to being read by third parties. This is enough to scare quite a few users into hitting the Cancel button. In other browsers, the email-composition window will open, but nothing will be filled in.

Client-Side Form Processing with the Set Text of Text Field and Change Property Behaviors

Forms can also partake of purely client-side scripting (for example, JavaScript carried out by the browser). Interacting with form elementschoosing items from a drop-down menu, selecting a check box, and so oncan trigger JavaScript behaviors. And form elements can be dynamically updated by a JavaScript without having to reload the entire page.

Together, these two facts make it possible to create forms that adapt their information display as the user is interacting with them.

In Dreamweaver, the Set Text of Text Field and Change Property behaviors give you access to some of this client-side processing. Set Text of Text Field lets you dynamically change the text in any of your form's text fields. With Change Property, you not only can change text in a text field or area, but you also can change the selected item in a drop-down menu or change the selected state of radio buttons and check boxes.

To use the Set Text of Text Field behavior, start by creating a form with at least one text field that you want to change. Next, select the page element that you want to trigger the change. This can be another form element, linked text, an image, or any other element that can have behaviors attached to it. From the Behaviors panel Actions list, choose Set Text > Set Text of Text Field. When the dialog box appears (see Figure 9.21), enter any text that you want to appear there.

Figure 9.21. The Set Text of Text Field dialog box.

The text that you enter doesn't have to be plain old text. Any valid JavaScript function call, property, global variable, or other expression can also be embedded in the text. A JavaScript expression must be placed inside braces ({}). So, an expression like this:

 The URL for this page is {window.location}

would display text like this:

 The URL for this page is http://www.mysite.com/mypage.html

To use the Change Property behavior, Start by creating a form with either a text field, a text area, a list/menu, a radio group, or a check box that you want to dynamically change. Next, select the page element that you want to trigger the change. From the Behaviors panel Actions list, choose Change Property.

When the dialog box appears (see Figure 9.22), it has a variety of options to choose from because this is a generic behavior that can be used on more than just form elements. From the Type of Object menu, choose the type of form element you want to change. From the Named Object list, choose the particular element that you want to change. The Property list then gives you a choice of all changeable properties for this element, as supported by different browsers. Luckily, all but the oldest browsers support changing basic properties of form elements. For different form elements, here are your options:

Figure 9.22. The dialog box for the Change Property behavior, with form element property changes showing.

For check boxes and radio buttons, the checked property determines whether the item is selected. To change this, enter true or false in the Value field at the bottom of the dialog box.
For text fields, password fields, and text areas, the value property determines what text appears. To change this, enter the text that you want to appear in the Value field at the bottom of the dialog box. Unlike the Set Text of Text Field behavior, JavaScript expressions entered in the value field aren't evaluated.
For select elements (for example, list/menus), the selectedIndex property determines which item in the list is selected. It works like this: Each item in the list has its own index number, starting from 0 for the first item. Determine the index number of the item that you want to have selected, and enter it in the Value field at the bottom of the dialog box.

Exercise 9.3. Using the Set Text of Text Field Behavior

In this quick exercise, you'll get a chance to see some more client-side form processing. You'll also see how form elements can be used to trigger behaviors. If you haven't done so already, download the chapter_9 folder from the book's website to your hard drive and define a site called Chapter 9, using that as the local folder.

In the chapter_9 folder, open mathpage.html and examine it. You'll see that it contains a form with several text fields and a Submit button (see Figure 9.23). Select each form field; you'll see that their names are num1, num2, and finalnum. Select the form; you'll see that its name is myForm. These are all important bits of information for processing the script.

Figure 9.23. The mathpage.html form, ready to do some calculating.

Can you guess what the game is? The user should be able to type two numbers in the top two fields, click the button, and get a result.
This form requires some processing of information, but it doesn't need to talk to a web server. It doesn't need to call an actions page, either. So, it doesn't need a Submit button. Select the Submit button and, in the Property Inspector, change its Action from Submit to None. You've just canceled the Submit button's built-in functionality. Now change its value to Calculate.
When the user clicks the Calculate button, the finalnum text field should display the result of adding the previous two fields. The Calculate button needs to trigger the Set Text of Text Field behavior.

Select the Calculate button. In the Behaviors panel, click the + and choose Set Text > Set Text of Text Field from the Actions list. When the dialog box opens, enter the following:
```
 {myForm.num1.value + myForm.num2.value} 
```
The brackets indicate that you're entering a JavaScript expression. The expression tells the browser to add the values of the num1 and num2 fields, within myForm. Click OK to close the dialog box.
In the Behaviors panel, double-check the behavior's event handler. It should be onClick . If it's anything else, change it.
Try it out in a browser. Enter two numbers in the top fields and click the Calculate button. There's some client-side form processing in action and dynamic updating of form elements.

Exercise 9.4. Using Change Property to Dynamically Update a Form

In this exercise, you'll tweak the Supersite form you built earlier in this chapter. When the user changes one form element, you'll use that to trigger changes in other form elements.

Start by opening the evalform.html file that you worked on earlier. The check boxes include an All of the Above option. Presumably, if the user checks this option, the three check boxes above it should also be checked.

Select the All check box (the one labeled All of the Above). In the Behaviors panel, click the + button and choose Change Property from the Actions list. When the dialog box appears, choose Input/Check Box for the Type of object, and the dw check box for the Name of Object. The property to change should default to checked. In the drop-down menu of target browsers, choose IE4. In the New Value field at the bottom of the dialog box, enter true (see Figure 9.24). Click OK to close the dialog box.

Figure 9.24. Using the Change Property behavior to change the checked property of one check box, triggered by another check box.
When the behavior is inserted, note the event handler specified in the Behaviors panel. It should be onClick .
Try it out in the browser. Clicking the All of the Above check box not only checks it, but it also checks the Dreamweaver check box.
Repeat the procedure two more times, adding two more instances of the Change Property behavior to the All check box to change the Fireworks and Flash check boxes.
Now, if you use all of that software, you must be a power user. So how about also changing the userlevel List/Menu? Again, select the All check box and add a new Change Property behavior. This time, choose Select for the object type, userlevel for the object name, and selectedIndex for the property. Leave the browser drop-down menu at IE4. The Power User option is the fifth item in the list, which gives it an index number of 4 (counting starts from 0, remember). So, enter 4 in the New Value field (see Figure 9.25). Click OK to close the dialog box.

Figure 9.25. Using the Change Property to change the selected item in a drop-down menu.
Try this out in a browser. Checking the All of the Above button turns on all other check boxes and sets the User Level drop-down menu to Power User. That's how form elements can dynamically update themselves based on user input.

Form Validation with the Validate Form Behavior

There's no point in submitting a form if vital information is missing or incorrectly entered. In fact, depending on the script that will be processing the form and how much error-checking it has built in, missing information might cause errors on the server. The most efficient course of action is to make sure all required form entries are present and valid before submitting the form. This is generally done using a JavaScript that executes when the user clicks the Submit button. The process is called form validation .

Dreamweaver's Validate Form behavior lets you specify that certain fields must be filled in and/or must include a certain kind of content (such as a number or email address) before the form is considered valid. To use the behavior, do this:

First, completely design your form and make sure all form fields have been named.
You can attach the behavior to the form itself or to the Submit button. To attach the behavior to the form, put the insertion point inside the form and use the Tag Selector to select the form tag. To attach the behavior to the Submit button, select the Submit button.
In the Behaviors panel, click + and choose the Validate Form behavior from the Actions list. In the dialog box that appears (see Figure 9.26), all text fields in your form are listed by name. For each field, select the field and choose whether it's required and whether it requires a specific kind of information. When you're done, click OK to close the dialog box.

Figure 9.26. The Validate Form behavior dialog box.
If you chose to attach the behavior to the form, make sure the Behaviors panel shows that the behavior is added to the onSubmit event handler. If you attached it to the Submit button, make sure the behavior is added to the onClick event handler.

Regardless of where you attached the behavior, it will execute when the Submit button is clicked, before the form is submitted. If there's a problem, it will stop the form from being submitted and display an error message (see Figure 9.27).

Figure 9.27. An invalid form (missing required information) causes the Validate Form behavior to display an alert message like this one.

You can test the Validate Form behavior offline by previewing it in the browser because it gets executed by the browser. Only if the form is valid will the browser try to submit it.

The behavior validates only text fields, not drop-down lists or any other form element.

Unless you're very comfortable with JavaScript, you probably don't want to go messing around with how the Validate Form behavior behaves. But as long as you're a careful typist, you can customize the text of the alert message that appears when a form is invalid. Go to Code view, find the MM_validateForm() function, and within that find the line of code that looks like this:

 } if (errors) alert('  The following error(s) occurred:   \n'+errors);

You can enter your own brief statement in place of the text marked in bold here. If your message contains any apostrophes or single or double quotes, however, you'll need to escape them by typing a backward slash (\) in front of them:

 } if (errors) alert('Your form can\'t be submitted because:  \n'+errors);

Your customized message should stay in place even if you edit the behavior.

Exercise 9.5. Attaching the Validate Form Behavior to the Submit Button

In this exercise, you attach the Validate Form behavior to the form's Submit button to check the text fields in your form before submitting it to the server. This exercise builds on Exercises 11.1 and 11.2, which should be completed before you proceed with this exercise.

If you haven't done so yet, download the chapter_09 folder from the book's website to your hard drive. Define a site called Chapter 9, with this folder as the local root folder.

Open your evalform.html document from Exercise 11.1. Select the Submit button at the bottom of the form.
In the Behaviors panel, click the plus (+) button and, from the Actions list, choose Validate Form. This opens the Validate Form dialog box.
Select the text field you named fullname. Select Required so that the field has to contain some data. From the Accept options, select Anything.
Then select the text field you named email. Again, select Required. This time, however, from the Accept options, select Email Address. This requires that this field at least contain an at sign (@) to be accepted.
Click OK to insert the behavior.
Save the document and preview it in a browser. You can test the form, to some extent, without having it actually connected to a script; when you press Submit, the browser will return an error message because you haven't specified a place to submit the data. Before you receive that error message, however, you can observe the Validate Form behavior in action. Try submitting the form without filling in a name; you should get an error message in the form of a small gray browser pop-up box. Then try it with a name filled in, but with an invalid email address containing no at sign (@); you should get another error message.