Copyright © 1999 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. XHTML Extended Forms is a major revision of HTML Forms. Key goals for the next generation of web forms include 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.
This draft only differs from the previous version by the addition of the email address for providing feedback.
After careful consideration, the HTML Working Group has decided that the goals for the next generation of forms are incompatible with preserving backwards compatibility with browsers designed for earlier versions of HTML. It is our objective to provide a clean new forms model ("XHTML Extended Forms") 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.
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 XHTML Extended Forms focusses on the increasing demands for improved human-computer interaction as well as the interaction mechanisms between the browser (user agent) and the server.
This document provides a comprehensive set of requirements for W3C's work on XHTML forms. 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.
The Web is experiencing a rapid growth in the variety of devices and applications. To meet this challenge, form fields should not be bound to a particular realisation as a control. 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.
Example: In previous versions of HTML, different markup was used for fields realised as radio buttons or as pull-down lists. Both permit the user to choose a single item from a group. On a Voice browser, there is no obvious difference between the two.
Forms need to be expressed as a well-formed XML. This ensures that user agents can rely on standard parser technologies. The form semantics (fields and form logic) should be expressed directly in XML to avoid the need for user agents to support additional syntaxes, for instance full scripting languages, which may be impractical for devices with very limited resources.
Note: An exception to this requirement may be a lightweight, spreadsheet-like expression syntax e.g. for simple field calculations. In today's Web forms, a substantial part of the form is often defined in ECMAScript although it would potentially be possible to define it entirely in markup. This forces user agents to understand ECMAScript in order to process rich web forms.
The need for a broadly applicable way for expressing the navigation paths within a form without implying specific user interface devices such as a mouse or standard keyboard. The navigation should be made explicit for each form control by clearly marking its relative ordering with respect to other controls, but 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.
The next generation of Web forms should be fit for usage with non-western character sets, languages, and writing systems. The requirement that non-western characters are preserved from their initial entry in a form field until their final destination and vice versa.
Note: Unicode is a key part of the solution, but is not yet widely supported by Web servers. It may be appropriate for forms to express the character repertoire accepted by a server. Character entities and ASCII transliterations may also play an interim role. This area is still under discussion.
The need to enable multi-national entry of data formats for common types like dates, currency, zip codes and phone numbers. Requirement 2.3.3 "Data Formats and input validation" addresses the need for constraining the data being entered into a field. These field constraints shall not force international users to adapt to western data formats if the corresponding data format is substantially different in other regions.
Postal addresses, dates, currency values and phone numbers vary in their details from one country to another. Forms designed for international access should to be able validate such fields taking the user's locale into account. The labels, sizes and input constraints for subfields need to adapt to the locale. For instance, a subfield for the postal code should ask for a "Zip code" in the US and for a "Post code" in the UK.
Note: If order forms are designed for the United States, then users in other countries may be unable to enter their postal codes in the field provided. US Zip codes are restricted to digits whereas postal codes in the United Kingdom are composed from letters and digits. If the Zip code field is required, a UK customer won't be able to complete the order form. US addresses also always include a "city", but this isn't true for other countries, leading to puzzlement when filling out the form.
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. XHTML forms need to be accessible as part of XHTML documents.
It should be possible to perform client-side calculations based on entries in form fields. A frequent need is the ability to compute a value on-the-fly according to a mathematical expression involving the previous field entries (e.g. the total sum in an order form). There needs to be a simple syntax for expressing field calculations, that can be easily parsed and processed by a wide variety of user agents.
The forms language should include a set of common data types as well as a mechanism for authors to specify custom data types.
There is the need for an author to be able to express the ways in which the user agent should behave when the user conflicts with the restrictions defined by a data type.
A means should be provided for expressing dependencies between fields or fieldsets. It should be possible to constrain a field so that it can only receive the focus if another field has been filled out. Additionally, a similar mechanism is needed for defining when two or more form fields are bound 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 fields that support multiple entries, such as an order list, it should be possible for the form control to dynamically adjust to permit the entry of further entries. It should be possible to specify the initial and maximum number of entries.
Example: This is important for applications such as order lists, where each product ordered needs the user to enter the quantity, product code etc. In this scenario, it should be possible to order as many different products as desired. Once the last slot is filled out, another one is created and presented to the user.
It should be possible for forms to extend across several Web 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.
A large form may be viewable as a single Web page on a desktop computer, but on a palm sized device, it may need to be presented as a sequence of smaller pages.
The scheme used by form logic to address form fields should be insensitive to transformations of the XHTML document it belongs to, rather than being tied to the specific representation in XML. A forms oriented addressing scheme would be based on the logical model of forms and be designed to simplify scripting.
Since the current interaction model between the browser and the server is rather limited, improvements are needed in the submit model for forms, providing for more advanced methods for exchanging data between the user agent and a remote entity such as the Web server. It should be possible for data to be inserted into a form and submitted back to a server in richer ways than flat name/value pairs.
Note: The Working Group suggested allowing the use of arbitrary XML namespaces for form data, which would also make it easy to sign the forms.
It should be possible to perform secure, protocol-independent form transactions as well as to be able sign a form and to work with signed forms. There should be a way to control access to a form or to sections of a form based upon user authentication.
Note: The forms subgroup is exploring what is needed for a form to become a legaly binding entity, and what constraints this requirement has on the design of the new forms model. Coordination is needed with the XML-Digital Signature Working Group.
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.
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. 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.
Note: This might lead to a new submit method "save", where the entire form together with the modifications made by the user is submitted back to the server. Apart from other benefits, this could be a simple mechanism of editing and updating XHTML documents over the web within user agents.
It should be possible to layout forms using HTML tables. It should be possible to style forms using style languages such as CSS and XSL. Forms should be usable in combination with emerging standards for vector graphics and dynamic effects based upon SVG and SMIL. In general, XHTML Extended Forms should use the presentation and layout mechanisms available to XHTML, instead of defining seperate layout mechanisms designed specifically for forms.
Graphical user interfaces have evolved rapidly in the last few years, but the Web has been slow to respond. The variety of forms controls should be increased 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.
Example: Some possible ideas for new controls include: expandable and collapsable tree controls, list-sort controls, editable combobox controls, sliders and rotary controls. Designers would value the ability to customize controls, e.g. using images.
There should be a way to define new form controls (perhaps using other markup languages such as SVG) offering a custom look and feel but integrated into the forms model so that they internally behave and react like a standard form control.
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):