W3C Logo

XHTML Extended Forms Requirements

World Wide Web Consortium Working Draft 30th August 1999

This Version:
Latest Version:
Previous Versions:
http://www.w3.org/MarkUp/Group/1999/xhtml-forms-req-19990727 (W3C Members only)
http://www.w3.org/MarkUp/Group/1999/forms-req-19990629 (W3C Members only)
http://www.w3.org/MarkUp/Group/1999/forms-req-19990422 (W3C Members only)
Sebastian Schnitzenbaumer <schnitz@overflow.de>, Stack Overflow
Malte Wedel <malte@overflow.de>, Stack Overflow
Dave Raggett <dsr@w3.org>, W3C/HP (HTML Activity Lead)


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.

Status of this document

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).

Table of Contents

1. Introduction

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.

2. Requirements for XHTML Extended Forms

2.1  Interoperability and Accessibility

2.1.1  Separation between purpose and presentation

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.

2.1.2  Definition of form functionality in XML

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.

2.1.3  Device and application independent navigation

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.

2.1.4  Device and application independent event syntax

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.

2.2  Internationalization

2.2.1  Support for various languages and character sets

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.

2.2.2  Region-specific data formats

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.

2.2.3  Region-specific common field groups

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.

2.3  Forms Logic

2.3.1  Integration with the XML DOM

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.

2.3.2  Field calculations

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.

2.3.3  Data types

The forms language should include a set of common data types as well as a mechanism for authors to specify custom data types.

2.3.4  Input validation

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.

2.3.5  Field and data dependencies

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.

2.3.6  Defining fields or fieldsets for arbitrary instances

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.

2.3.7  Splitting a form across multiple pages

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.

2.3.8  Forms oriented addressing scheme

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.

2.4  Interaction

2.4.1  Richer client/server interaction mechanisms

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.

2.4.2  Security and authentication

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.

2.4.3  Broader range of input devices

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.

2.4.4  Preserving the current state of a form

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.

2.5  Presentation

2.5.1  Alignment with existing and emerging presentation mechanisms

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.

2.5.2  Enhanced visual possibilities for form controls

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.

2.5.3  Custom form controls

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.

3. Acknowledgments

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):

Frank Bouphrey, HTML Writers Guild
Sam Dooley, IBM
Martin Dürst, W3C
Warner ten Kate, Philips
Paula Klante, JetForm
Dave Manning, UWI
Mike Mansell, UWI
Larry Masinter, Xerox
Gavin McKenzie, JetForm
Dave Raggett, W3C/HP (HTML Activity Lead)
Patrick Schmitz, Microsoft
Sebastian Schnitzenbaumer, Stack Overflow (Chair)
James Salsman, Cisco
Peter Stark, Phone.com
Malte Wedel, Stack Overflow

4. References

"The future of HTML Forms", Dave Raggett, 16th January 1999.

This is a discussion document setting out some possible directions for the HTML working group to consider for the next generation of HTML forms. It is proposed that the group begin work on a public working draft setting out requirements for the next generation of HTML forms, with the goal of soliciting feedback from W3C members and the general public, and then to proceed to the development of a proposed recommendation of a form module for use with HTML and other XML formats.
Available at: http://www.w3.org/MarkUp/Group/WD-forms-ng.html (W3C members only)
"XML Forms Architecture (XFA) 1.0", Gavin McKenzie, 14th June 1999.

The document "XFA-Template" describes the open and extensible modeling of secure forms with high fidelity composition, automated calculation and validation, pluggable user-interface components, and flexible data handling. The document "XFA-FormCalc" describes a simple scripting language optimized for creating electronic-form centric logic and calculations. XFA provides for the specific requirements of electronic forms and the applications that use them. XFA addresses the needs of organizations to securely capture, present, move, process, output and print information associated with electronic forms.
Submitted to W3C 14th May 1999. Available at: http://www.w3.org/1999/05/XFA/xfa-template.html(XFA-Template)
http://www.w3.org/1999/05/XFA/xfa-formcalc.html (XFA-FormCalc)
"Forms Markup Language (FML) 0.8", Sebastian Schnitzenbaumer, Malte Wedel, Muditha Gunatilake, 24th June 1999.

This document describes an XML syntax for a Forms Markup Language. The purpose of FML is to redefine and enhance the representation and handling of web application interfaces in the tradition of the HTML 4.0 forms tagset. Key problems for FML to solve are the definition of dynamic forms, online wizards and web applications that cover multiple screen pages but originate from a single FML document, including input validation, navigation, event handling, template management and run-time calculations.
Available at: http://www.mozquito.org/xhtml-fml08
"Extensible Forms Description Language (XFDL) 4.0", John Boyer, Tim Bray, Maureen Gordon, 2nd September 1998.

This document describes an XML syntax for the Extensible Forms Description Language (XFDL). The purpose of XFDL is to solve the body of problems associated with digitally representing complex forms such as those found in business and government. The requirements include support for high precision layout, supporting documentation, integrated computations and input validation, multiple overlapping digital signatures, and legally binding auditable transaction records, by maintaining the whole form as a single unit such that digital signatures can capture the entire context of transactions.
Submitted to W3C on 2nd September 1998. Available at: http://www.w3.org/TR/NOTE-XFDL
"Form-based Device Input and Upload in HTML", James Salsman, 2nd July 1999.

Proposes an extension to the HTML INPUT TYPE=FILE form element specified in RFC 1867 to allow information providers to express requests for uploads from audio and other devices uniformly. Motivations, including language instruction assistance, voice transcription, and other applications, conclude.
Submitted to W3C on 2nd July 1999. It can be found at: http://www.w3.org/1999/07/NOTE-device-upload-19990706
"Formsheets and the XML Forms Language", Anders Kristensen, 11th May 1999.

This Paper describes a means to construct data for submission to a server from an XML form using a stylesheet-like mechanism. This paper was presented at the WWW8 conference held in May 1999.
Available at: http://www.hpl.hp.co.uk/people/ak/doc/XForm.html
"User Agent Authentication Form Elements", Scott Lawrence, Jim Gettys, Paul Leach, 3rd September 1998.

This document proposes a new HTML capability to aid in the development of authenticated web user interfaces. This proposal suggests extensions to HTML forms to overcome their present security problems by integrating them with HTTP (or other security sublayer) mechanisms. It calls for a new type of form; the AUTHFORM and new values for the TYPE attribute of the INPUT element and SELECT block.
Submitted to W3C on 3rd February 1999. Available at: http://www.w3.org/MarkUp/Group/Contrib/Lawrence/authform-980903.html (W3C members only)