Moving to a new standard: HTML gets a makeover, part two
What are the new form features in HTML 4.0?
HTML 4.0 is the version we've all been waiting for. In the second installment of a three part series, Chuck Musciano takes a look at the new form features in HTML 4.0. (2,000 words)
Unfortunately, most Web-based forms are unattractive, simplistic, and meager compared to the rich user interfaces presented by other desktop tools. HTML 4.0 begins to correct those deficiencies by adding a few new features to forms that will make your pages easier to read, easier to use, and easier to create.
Buttons have always been an afterthought in the world of HTML forms. Prior to version 4.0, textual buttons were created differently than graphical buttons, and the special Submit and Reset buttons were handled separately. Because buttons are a staple of any user interface, this made forms programming that much more difficult for the novice.
HTML 4.0 corrects much of this by consolidating all the existing
buttons features into a new tag,
all the old ways of creating buttons using the
<input> tag are retained, you'll find the new
<button> tag more consistent, easier to use, and
offering button capabilities that were previously not available.
<button> tag uses three main attributes:
type. As you
value provide the
name/value pair to be passed to the server when the form is submitted.
type attribute defines the kind of button to be
reset, or a plain
When buttons were created with the
the button label was defined with the
Graphical buttons used
type=image and provided an image
src attribute. In HTML 4.0, the
<button> tag has content; that content forms the
button label. Textual, graphic, and mixed label buttons all are
created in a similar manner.
For example, here are several buttons as they might be created in HTML 3.0:
<input type=button value="Button Label"> <input type=image src="http://server.com/image.gif"> <input type=submit value="Submit"> <input type=reset value="Reset">And here are their equivalents in HTML 4.0:
<button type=button>Button Label</button> <button type=button><img src="http://server.com/image.gif"></button> <button type=submit>Submit</button> <button type=reset>Reset</button>Of course, the best part is a mixed label button, impossible before HTML 4.0:
<button type=button><img src="icon.gif"> Click me!</button>This would create a button with an icon and accompanying text.
Most user interfaces associate labels with interface elements, especially when text fields and choice items are presented. Because the labels are bound to an element, the user interface can provide more compelling interaction to the user, reacting when focus changes to the element or when the user clicks on the label.
HTML 4.0 adds labels to your forms using the
tag. The contents of the tag are used to render the label, and the
for attribute binds the label to an element in your form.
The value of the
for attribute is a name associated with a
form element using the
id attribute with that element.
This is easier to see than it is to explain. Here is a text entry field with a label:
<label for=tfield1>Name:</label> <input type=text id=tfield1>
While each label in your form can be associated with a single element, one element can have many labels attached to it.
If you have an aversion to the
attributes, you can bind a label to an element by placing the element
<label>Name: <input type=text id=tfield1></label>
The one thing that the
<label> tag does not do is manage
the layout of
the label with respect to its element. You will still need to use your
table layout tricks to get things to look right. In these cases,
you'll be forced to use the
attributes, as the second style of labelling doesn't work across
Often, the elements within a form are themselves collected into several related groups. For example, you might create a set of text fields for name and address, a set of radio buttons for ordering options, and a third set of elements for capturing credit card information. You might draw a box around these items, or somehow set them apart within your interface.
HTML 4.0 gives you this ability with the
<legend> tags. The
<fieldset> tag lets you collect a related set of
elements into a group, and the
<legend> tag provides
a name for the group. The actual rendering of the group is left up to
the browser, but you can imagine it might include boxes and appropriate
shading. More importantly, non-visual browsers can use the grouping
and legend information to better present your form in another medium.
<fieldset> tag has no special attributes, and
<legend> tag accepts an
that advises that the legend is to be placed at the
right of the
group. These tags are used like this:
<fieldset> <legend align=left>Address</legend> ...address labels and fields go here </fieldset> <fieldset> <legend align=left>Credit Card</legend> ...credit card labels and fields go here </fieldset>
<legend>s should make your forms easier to navigate
and more visually appealing.
In HTML 3.2, pulldown menus were easily created with the
<option> tags. The
resulting menus were usually attractive and easily used. The only
problem came when you needed to add lots of elements to the menu: Because
no nesting ability was provided, menus could easily grow to dozens of
items. It isn't uncommon to visit pages with machine-generated menus
that are too large to fit on the display.
HTML 4.0 brings some relief to the problem with the introduction of the
<optgroup> tag. This tag is used within a
<select> tag to collect related
<option> tags into a group. This group is then
rendered as a pull-right submenu within the main menu. The
<optgroup> tag accepts the
attribute, which provides a label for the pull-right menu.
Consider this menu:
<select> <option>Basset Hound</option> <option>Beagle</option> <option>Bloodhound</option> <option>German Shepherd</option> <option>Collie</option> <option>St. Bernard</option> <option>Dandy Dinmont Terrier</option> <option>Norwich Terrier</option> <option>Welsh Terrier</option> <option>Cocker Spaniel</option> <option>Gordon Setter</option> <option>Pointer</option> </select>
If this menu contained all 145 breeds of dogs, it would be
unmanageable. Using the
makes things easier for the user:
<select> <optgroup label="Hounds"> <option>Basset Hound</option> <option>Beagle</option> <option>Bloodhound</option> </optgroup> <optgroup label="Working Dogs"> <option>German Shepherd</option> <option>Collie</option> <option>St. Bernard</option> </optgroup> <optgroup label="Terriers"> <option>Dandy Dinmont Terrier</option> <option>Norwich Terrier</option> <option>Welsh Terrier</option> </optgroup> <optgroup label="Sporting Dogs"> <option>Cocker Spaniel</option> <option>Gordon Setter</option> <option>Pointer</option> </optgroup> </select>
This lets the user select the type of dog, and then choose a specific breed.
The only drawback to the
<optgroup> tag is that it
cannot be nested, preventing multiple levels of menus. This is an odd
restriction, given that most other HTML elements can be nested to most
any level. Browsers may lift this restriction, and we may see this
changed in a future version of HTML.
While the mouse is an integral part of any user interface, it is still true that many users move around a form by tabbing between the fields. In earlier versions of HTML, the only way to control the order in which users could tab between elements was by changing the order in which the elements appeared in the HTML source file. Because elements are often jumbled up in order to achieve certain layout effects, this made any sort of effective tab sequence next to impossible. HTML 4.0 neatly fixes this problem by expanding all form elements to accept the
taborder attribute. This attribute accepts a numeric
value that defines the element's position in the form tab sequence.
Tabbing starts with the element assigned a tab order of one. It then
proceeds numerically, moving to the next higher value in the tab
sequence. Elements that are not given a tab sequence, or that have a
tab order of zero, are moved to the end of the tab sequence and are
visited in the order in which they appear in the HTML source file.
Elements that are disabled (grayed out) do not participate in the tab
modify a form's tab sequence on the fly, if need be, by changing the
value of the
taborder attribute for an element.
taborder attribute is not limited to form elements.
HTML 4.0 also allows this attribute to be used with the
<a> tag and the
<area> tag. This
means that your hyperlinks can be accessed by tabbing to them, and that
areas within your image maps can be reached in a similar fashion. This
is especially important for non-graphical browsers like Lynx, which use
tabbing as a primary form of navigation. For the first time, you can
control the order in which Lynx moves between the links in your
Along with the notion that users will navigate through your interface using the tab key, most interface designers expect that expert users will learn and use keyboard accelerators to access elements within the interface without using the mouse. The details of how this works vary between platforms (the Alt key usually handles this function in Windows, while Unix users press the Meta key to access an accelerator) but the net result allows most interface elements to be reached with a single keystroke.
In HTML 4.0, you can define accelerator keys for your interface
elements using the
accesskey attribute. The value of this
attribute is a single character that is associated with the element in
a platform-specific way. You can use the
attribute with the
<button accesskey="S" type=submit>Submit</button>associates the S key with this button. Presumably, the browser will find and render the S in the button label differently, as a clue to the user that the accelerator key can be used.
If an accelerator key is defined for a
<legend> tag, the corresponding element or
<fieldset> is given the input focus when the
accelerator key is pressed.
accesskey can also be used
Typing the associated accelerator key is the same as clicking or
otherwise selecting the hyperlink created by the tag. For example,
<a href="index.html" accesskey="H">Home Page</a>
creates a link to your home page that can also be reached by having the user type Alt-H (or its equivalent on your system). Used correctly, accelerator keys can make your documents even easier to use, creating consistent keystroke actions throughout your documents.
The only bad news regarding HTML 4.0 forms enhancements is that none of them are supported by the current crop of browsers. While it makes sense to understand these new features and to plan how you might use them in your pages, you'll have to wait a while before you can test them out, and even longer before new browsers penetrate the market enough to make their use worthwhile. In the meantime, plan on showing up next month, when we finish up with all the other nifty stuff you'll find in HTML 4.0.
About the author
Chuck Musciano has been running various Web sites, including the HTML Guru Home Page, since early 1994, serving up HTML tips and tricks to hundreds of thousands of visitors each month. He's been a beta tester and contributor to the NCSA httpd project and speaks regularly on the Internet, World Wide Web, and related topics. Chuck is currently CIO at the American Kennel Club. Reach Chuck at firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com