Under-implemented Input Behavior

Now that you know the details of the principal elements for gathering user input, let's wrap this chapter up with a look at some of their less-frequently implemented aspects. This section will cover some of the WML elements and attributes that seem to be very good ideas for high-fidelity platforms, such as HTML browsers, but may be overkill for this low-fidelity platform.

Extended Attributes

Both the input and select elements support the tabindex attribute. This attribute should behave much the same as its namesake in HTML 4. You add it to the element declarations to cue the browser where the user should move to each time she presses the Tab key.

This tabbing order should define the sequence the user will visit the input fields on a card. Unfortunately, few actual WML browsers have input devices with Tab keys. In fact, the specification recommends that you assume the browser does not have a Tab key but will behave properly anyway.

The specification supplies the accesskey for many elements, the input, option, and anchor included. This attribute permits you to associate a "hotkey" with an input field so that the user can quickly skip to a field. Pressing the key should give focus to the associated input element.

Of course, because screens on WML browsers are often very small, it's likely that there will only ever be two or three input or option fields visible at any one time. It's unlikely that the user would move from the familiar up/down scroll control to the access key to save one press. Further, the browser is not required to give any visual cue as to what the access key is, nor would it be practical—this makes learning the key nearly impossible.

Lastly, the WML specification creates the title attribute for many elements. This attribute is not completely unimplemented in practice; in fact, the card and optgroup elements created by Listing 7.20 use this to cue the user.

The title element is, however, overabundant. It is available for table and input elements where there is typically no room available to display their values. The HTML 4.0 analog of this attribute is used for helpful annotations, a luxury that is almost never available on WML browsers.

Future WAP browsers, that have larger screens and more complete input devices, may be able to take advantage of these extended attributes. These attributes are clearly aimed at hardware that is much further advanced than that on the market at the time of this writing.

As device hardware becomes more powerful, this language may become obsolete: replaced by the lingua franca of distributed applications—HTML. I recommend against using any of these attributes in your code now and expect future devices to handle them properly. You should simply create the simplest, most direct WML decks possible and ensure correct behavior on as many current, real browsers as resources allow.

Layout with <fieldset>

The WML specification provides the fieldset element for grouping input fields. Just as I showed with the attributes in the last section, this element is very forward thinking. It anticipates WAP applications that place many input fields on a single card and gives you the ability to group them logically for the user.

A fieldset element logically separates one set of input from another on a single card. It can contain almost any element that you can place directly on the paragraph, including itself. The browser will need not display any indication of a boundary between fields, nor does it need to respect their presence and create a logical separation.

This capability is just not something that you require or desire with real devices that will hit your applications. You should design your applications so that the user is not faced with many input fields; they are frustrating to use because the input hardware is almost always very limited.