3.1 XForms User Interface Design

3.1 XForms User Interface Design

We begin this chapter with an overview of the design philosophy that motivated the creation of the XForms user interface vocabulary. The primary goal as we overhauled HTML forms from 1993 was to make the next generation Web forms technology robust with respect to accessibility, internationalization, and the ability to deliver user interaction to a variety of modalities and end-user devices. Looking forward to a ubiquitous Web that would be accessible using devices and modalities best suited to a user's needs and abilities at a given time meant that we had to step back from commonly held notions of visual interaction and create an abstract user interface vocabulary capable of withstanding the test of time. [1]

[1] Or at least survive as long as HTML forms from 1993 have survived!

Addressing the need to create an abstract user interface vocabulary had the advantage of contributing directly to our primary goals of accessibility. Once we freed the user interface vocabulary from fixed ideas driven purely by visual interaction, we were able to leverage the separation of the XForms model from the user interface to the fullest degree in creating a set of controls that could be easily retargeted to different user interaction environments. Cascading Style Sheets (CSS) is now a mature Web technology, and this has made it significantly easier for the XForms working group to defer stylistic and presentational issues to the CSS layer. Having separated out presentation by using CSS, we used the XML binding to DOM Events provided by XML Events to factor out interaction behavior of the various controls. Thus, the XForms user interface design separates content, presentation, and interaction to create an XML vocabulary that lends itself to intent-based authoring of user interaction:


Separating the model from the user interaction allows user interface controls to bind to display-independent content.


Factoring out presentation and style via CSS makes XForms user interface controls presentation independent.


Using XML Events to connect events and the actions they invoke enable XForms user interface controls to remain independent of specific user interaction environments. Thus, none of the XForms user interface controls as defined depend on specific UI peripherals such as mouse, keyboard, or monitor.

Once we had achieved the above three-way separation, it became possible to define a user interface vocabulary that encourages intent-based authoring. This style of authoring encourages authors to specify fully the underlying intent behind a given user interaction ”rather than the mere physical representation of a particular user interface. Thus, authors specify that the user should be allowed to pick from a set of choices via XForms element select ”rather than by hard-wiring a specific representation of such a control, for example, a list box.

The abstract nature of the XForms user interface vocabulary, combined with each XForms control encapsulating all the metadata needed to represent the user interaction effectively, makes it well suited for delivering applications to different modalities and devices. Notice that encapsulating such metadata as part of the user interface controls makes the resulting vocabulary accessible by design. This is a major step forward from the past where accessibility was typically bolted in after the rest of the system had been designed.

Table 3.1. Mapping HTML Forms Vocabulary to XForms

HTML Forms


input type ="text"


input type ="password"


input type ="textarea"


input type ="hidden"

Default ”values shown only when controls are bound

input type ="checkbox"

input bound to type xsd:boolean

input type ="radio"




input type ="submit"


input type ="reset"

trigger with handler reset

input type ="file"


input type ="image"

trigger with image label

input type ="button"


The effect of building accessibility as a first-class citizen into the XForms design is most noticeable when reading the XForms 1.0 specification, which makes very few explicit references to accessibility. This is not an oversight in the specification ”on the contrary, having designed XForms to be accessible and usable from the very beginning, the working group needed to say very little in terms of explicit accessibility guidelines when authoring XForms applications.

Finally, the XForms vocabulary was designed to be familiar to HTML authors in order to smooth the transition to XForms. HTML authors will recognize the equivalences shown in Table 3.1 between familiar HTML Forms constructs and their XForms counterparts.

XForms. XML Powered Web Forms with CD
XForms. XML Powered Web Forms with CD
Year: 2003
Pages: 94

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net