Copyright© 2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Forms were introduced into HTML in 1993 and have proven to be a valuable part of many Web pages. The experience of the last few years has led to demands for improvements to HTML forms. XForms are a major revision of HTML Forms. Key goals for the next generation of web forms include ease of migration, improved interoperability and accessibility, enhanced client/server interaction, advanced forms logic, support for internationalization and greater flexibility in presentation.
This is a public W3C Working Draft on requirements for the next generation of web forms. It is intended for review by W3C members and other interested parties. The document provides an overview of the requirements currently under discussion within the Forms Subgroup of the HTML Working Group.
This Working Draft may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current public W3C Working Drafts can be found at http://www.w3.org/TR.
This document is work in progress and does not imply endorsement by the W3C membership or the HTML Working Group (members only).
This document has been produced as part of the W3C HTML Activity. The goals of the HTML Working Group are discussed in the HTML Working Group charter (members only).
Please send detailed comments on this document to www-html-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on HTML features takes place on the mailing list www-html@w3.org.
[Ed. The forms public mailing list is www-forms@w3.org.]
After careful consideration, the HTML Working Group has decided that the goals for the next generation of forms are incompatible with preserving full backwards compatibility with browsers designed for earlier versions of HTML. It is our objective to provide a clean new forms model ("XForms") based on a set of well-defined requirements. The requirements described in this document are based on experience with a very broad spectrum of form applications.
This document provides a comprehensive set of requirements for W3C's work on XForms. We envisage this work being conducted in several steps, starting with the development of a core forms module, followed by work on additional modules for specific features. The Modularization of XHTML provides a mechanism for defining modules which can be recombined as appropriate to the capabilities of different platforms.
Web forms are being used in various contexts as a standardized mechanism for bidirectional data exchange over the web. In many occasions, it is desirable to enable an open data dialog between the recipient of a hypertext document and the sender. Forms need to provide effective support for various kinds of data exchange. The design of XForms focuses on the increasing demands for improved human-computer interaction as well as the interaction mechanisms between the browser (user agent) and the server.
To enable Web content developers to meet these challenges XForms will be designed to cleanly distinguish between form data, logic and presentation. The same form will be accessible as a sheet of paper or using a handheld computer resting on your palm.
To meet the goals for richer presentation XForms will be designed for integration with other XML tag sets, such as XHTML itself, SVG for graphics and SMIL for multimedia forms. You will be able to use style sheet languages such as CSS and XSL to finely tune the presentation.
As the cost and size of Web servers continues to shrink, single chip implementations are now practical, and we can soon expect to see all kinds of devices with embedded servers. XHTML will be used for controlling such devices, reducing the need for custom device drivers. XForms will be designed to provide the richer user interface these applications will need.
It is generally best to catch input errors early. This can be achieved with form logic that works with the user to ensure that the appropriate fields are filled out and that the values satisfy the appropriate consistency checks. For phone numbers and addresses, the checks will vary from one part of the world to another.
Complex forms are best presented as a sequence of sections, one section at a time. The ability to download the entire sequence in a single file makes it easy to fill out the form without a real-time connection to the Web server, and avoids the inevitable delays in reestablishing a connection to the server for each section.
For some applications, the process of filling out the form will be interleaved with searching for relevant information. This motivates the development of the means to suspend a form and to later resume filling it out, perhaps a considerable time later. This could occur explicitly at the users request, for instance, when filling out a tax return, or automatically when moving from one page to another on a home shopping Web site.
The main target audience for XForms is HTML 4 authors familiar with forms. XForms will make it simpler to build forms including the business logic, calculations, and form processing that in many cases has been done with client-side scripting.
Server-side programmers are also part of the target audience. In the past, deploying forms on a Web site involved complex server-side scripting to accept, validate, and process incoming data. XForms will make this easier by providing a consistent, XML-based format for incoming data, as well as by providing a rich validation framework.
Finally, application vendors that produce products that interact with forms are part of the target audience. By providing a vendor-neutral data model layer, XForms will provide an avenue for interoperability between various forms implementations.
XForms should be an application of XML 1.0 plus Namespaces. It should be possible to define a rich form, including validations, dependencies, and basic calculations without the use of a scripting language. XForms should be usable in XHTML and other XML-based languages, such as SVG. XForms should be usable by clients without XHTML capabilities.
XForms should be designed in such a way as to encourage users to make use of the new capabilities, rather than lingering on existing form technologies. Likewise, the design should encourage implementors to deploy user agents that implement XForms.
XForms should be straightforward to hand author, thus further encouraging migration from existing HTML forms.
XForms fields should not be bound to a particular interface representation. Instead the field should state the nature of the task the user is being asked to perform. The "purpose" of a form control may be the same on various devices, whereas the rendering may vary based on different capabilities.
It should be possible to access and manipulate forms via the XML Document Object Model. This is needed to allow the construction of specialized forms with behaviors going beyond the limits of the forms language itself. XForms should be accessible as part of an XML document, insensitive to changes in the enclosing document. Additional DOM convenience methods specific to forms will be added.
XForms should express the navigation paths within a form without implying specific user interface devices such as a mouse or keyboard. The navigation shouldn't rely on device-specific methods such as use of the "tab"-key.
It should be possible to express forms event handling for a broad range of devices. In previous versions of HTML some events were device-independent (e.g. onfocus, onblur, onchange), while others implied the availability of device-specific features (e.g. onmouseover, ondblclick). Within a single form, it should be possible to exploit events specific to different kinds of devices.XForms should be fit for usage with non-western character sets, languages, and writing systems, including support for Unicode. It is required that nonwestern characters be preserved from their initial entry in a form field until their final destination and vice versa. It should be possible to for entry of data formats that do not force international users to adapt to western data formats if the corresponding data format is substantially different in other regions. Forms designed for international access should to be able validate such fields taking the user's locale into account. Additionally, in forms designed for international access, labels, sizes and input constraints for subfields should be able to adapt to the locale.
Since smaller specifications are both easier to understand and easier to implement, XForms should be defined as modular, self-contained documents that can be independently brought to Recommendation status.
XForms should define a set of common data types as well as a mechanism for authors to specify custom data types. Data types should be defined with basic users in mind.
XForms should include a means for reuse of server-side code for processing subforms. It should be possible to uniquely and persistently name various data types.
XForms should be able to express restrictions on user-entered data, with enough sophistication to handle common cases, like "telephone number". XForms should define how the user agent should behave when the user-entered data conflicts with the restrictions defined by a data type.
In addition to legacy formats, XForms should be able to send submitted form data back to the server as well-formed XML.
XForms should include simple client-side calculations and expressions based on entries in form fields. Common tasks like summing multiple fields and calculating sales tax should be possible. The expression syntax needs to be simple enough to be easily parsed and processed by a wide variety of user agents. It should be possible to escape out to a scripting language for advanced processing.
XForms should be able to express dependencies between fields. It should be possible to constrain a field so that it can only accept input if another specific field has accepted input. It should be possible to bind two or more fields to the same data value, so that if the value in one field is updated, then the related form fields also take that value.
For field groups that support multiple entries, such as a line item on an order form, it should be possible for the form control to dynamically expand and contract to permit the addition or removal of further items. It should be possible to specify the initial, minimum, and maximum number of entries.
It should be possible to perform secure, protocol-independent form transactions. Current user agents typically implement HTTP authentication with a pop-up window requesting name and password. It should be possible for XForms to be used as a front end for HTTP authentication.
There needs to be a generalized way of preserving the changes the user has made to a form. This will make it possible for a user to save the form, and at a later time, to resume filling it out, perhaps from a different machine and perhaps with a different user interface. The ability to treat forms as persistent objects encapsulating state and behavior is needed for workflow applications where forms are passed from one user to another. It should be possible to merge independent updates to persistent forms in ways specific to individual applications.
Every form of user interaction defined in HTML 4 forms should be possible with XForms.
Compared to current web form technology, XForms should define richer form controls to match the expectations of designers, and to provide richer functionality for data acquisition. Designers should be given greater control over the visual appearance of form controls.
It should be possible for a form to be presented as two or more pages. This requirement permits the form to be treated as a single unit or as several parts. The form's logic should apply regardless of how it is split up.
Multiple data models should be able to exist within the same Web page.
Forms need to support a wide range of data acquisition techniques in addition to plain text. For instance, to enable the input of files, such as audio files, and the input of data streams from devices such as cameras, microphones and scanners. Also under consideration are pen-based inputs, which would allow signatures and other simple drawings to be entered directly into a form equipped with a suitable drawing canvas.
XForms should have no dependency on a particular presentation technology, for example XHTML tables.
We will investigate ways of achieving richer form layout and alignment on a wide variety of devices.
There should be a way to define new form controls (perhaps using other markup languages such as SVG, perhaps with bitmap images) offering a custom look and feel but integrated into the forms model so that they internally behave and react like a standard form control.
Further research into various additional graphical elements that will be useful as a part of XForms.
Further research into ways to make XForms more useful to aural user agents.
Further research into ways to make XForms more useful to paper processing and OCR user agents.
This requirements document was written with the participation of the members of the Forms Subgroup of the W3C HTML Working Group (listed in alphabetical order):