Moving to a new standard: HTML gets a makeover, part two
What are the new form features in HTML 4.0?
May 1998
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Moving to a new standard: HTML gets a makeover, part twoWhat are the new form features in HTML 4.0? |
May 1998
|
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)
 Mail this article to a friend |
n
last month's
Webmaster column, we began an extended tour through the new
features of HTML 4.0. We've
been through tables, and now our attention turns to
HTML 4.0
forms.
With the advent of Java, JavaScript, and other embedded objects, it's difficult to remember that just a few short years ago the only interactive elements on any Web page were HTML forms. These forms offered the basics of any point-and-click interface: buttons, text fields, radio buttons, checkboxes, and pulldown menus. With a bit of server-side programming, you could build Web pages that requested user input and delivered customized responses back to your visitors.
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.
Better buttons
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, <button>. While
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.
The <button> tag uses three main attributes:
name, value, and type. As you
would expect, name and value provide the
name/value pair to be passed to the server when the form is submitted.
The type attribute defines the kind of button to be
created, either submit, reset, or a plain
button.
When buttons were created with the <input> element,
the button label was defined with the value attribute.
Graphical buttons used type=image and provided an image
with the 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.
|
|
|
|
|
Lovely labels
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 <label>
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 for and id
attributes, you can bind a label to an element by placing the element
within the <label> tag:
<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 for and id
attributes, as the second style of labelling doesn't work across
table cells.
Great groups
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 <fieldset>
and <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.
The <fieldset> tag has no special attributes, and
the <legend> tag accepts an align attribute
that advises that the legend is to be placed at the top,
bottom, left, or 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>
Used correctly, <fieldset>s and
<legend>s should make your forms easier to navigate
and more visually appealing.
Marvelous menus
In HTML 3.2, pulldown menus were easily created with the
<select> and <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 label
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 <optgroup> tag
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.
Terrific tabs
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
sequence. Presumably, you could use JavaScript or a similar applet to
modify a form's tab sequence on the fly, if need be, by changing the
value of the taborder attribute for an element.
The 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
documents.
Excellent accelerators
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 accesskey
attribute with the <button>,
<input>, <label>,
<legend>, and <textarea> tags.
For example:
<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 <label> or
<legend> tag, the corresponding element or
<fieldset> is given the input focus when the
accelerator key is pressed.
Like taborder, accesskey can also be used
with the <a> and <area> tags.
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.
Testing time
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.
|
|
Resources
sed script http://members.aol.com/htmlguru/agent_log.html
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 chuck.musciano@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright98.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-05-1998/swol-05-webmaster.html
Last modified: