Introduction | Demos | Acknowledgements | Wiki | Relationship to XForms | Open Issues | Slides
The ability to collect data from users and to submit it to servers has proven to be a very important part of the Web. Forms are often supplemented by Web page scripts that enable the data to be checked as the user is filling out the form and before sending it to the server. These scripts can get quite complicated to develop and to maintain, making it interesting to explore ideas for replacing such scripts by equivalent declarative approaches.
XForms-Tiny is an incremental extension of HTML4 forms that is being defined by the W3C Forms activity as a way for Web application developers to leverage the XForms architecture to reduce the cost of deploying forms-based Web applications. Web developers who have existing forms assets, and who are reaching the practical limits of what they can do with HTML forms, can now take incremental advantage of the XForms architecture without first having to switch to XML.
XForms Tiny can be deployed on today's Web browsers using an open source cross browser script library that works on Internet Explorer 6 and 7, Firefox 1.5, Firefox 2, Opera 9, Konqueror 3.5, Safari, Opera Mobile 8.6 and NetFront 3.4. When delivered via HTTP as a compressed file, the download size is only 6 KBytes. The library is available now, and will be updated to reflect changes to the specification as XForms-Tiny progresses along the W3C Recommendation Track. The first public Working Draft specification is expected in the first quarter of 2007. This is aimed at authors and authoring tools, and will not require native browser implementations.
The testbed consists of a series of experiments that explore opportunities for stepping stones between the capabilities provided by HTML4 and the much richer capabilities provided by XForms. In particular, the means to use simple expressions for validating field values and spread-sheet like formulae for computed fields, but also the means to describe repeating groups of fields, e.g. for line items in a purchase order. XForms-Tiny further provides for suppression of irrelevant parts of forms and context dependent control over which fields must be filled out. All this is possible without the page author needing to write any lines of client-side script.
The XForms Tiny library makes it easy for developers to customize the presentation through the use of CSS style sheets and selectors based upon class names. The library dynamically updates the list of class names on elements to reflect the current state, with focus, invalid, missing, readonly, disabled and irrelevant as managed class names. CSS style rules can thus be used to highlight invalid fields and their labels, to change the background color for the currently focused field, and to hide irrelevant groups of fields.
Here is a list of demonstrators for different aspects of XForms-Tiny:
The library is available free of charge under W3C software licensing policy. The size of the library can be reduced by compressing it with gzip. The web browser is able to automatically decompress the file. Running Douglas Crockford's jsmin on the script before compressing it further reduces the library download size to 6 KBytes (minified version).
Work is underway to reflect changes as you type without waiting for the onchanged event. Other ideas include customizable support for errors and warnings, adding and removing rows from repeating field sets, and the use of Ajax for partial updates to the form's data and Web page content. Your feedback would be much appreciated. Better yet would be your help in further developing it. My contact details are at the bottom on this page. Comments are also welcomed on the W3C public discussion list for forms.
The specification for XForms-Tiny will be elaborated on the W3C Forms Working Group's public wiki. and will cover both the markup and the object model exposed to scripts. This will then be used as a basis for a W3C Working Draft.
I would like to express my gratitude to the WebForms 2.0 proposal which prompted me to do this work, and from which I borrowed a number of ideas, and which in turn were perhaps inspired from my earlier work in 1993 on fill out forms for HTML+. The current work extends HTML with a few new attributes, but could easily be used to export the equivalent XForms data model when content developers want to take advantage of the more sophistocated capabilities in XForms, for example, the ability to collect and submit structured data as XML. There are many other interesting ideas in WebForms 2.0, for example, control over whether autocompletion is enabled on form fields.
I am planning on updating the library to track the associated specification work in the W3C Forms working group. Currently I am expecting to work on the following:
The starting point is the idea that the architecture in XForms is more important than its syntax. The stepping stones I have been exploring are about how to make use of that architecture with only incremental extensions to the HTML forms syntax, and to do so in a way that can be used today with existing browsers without the need for plugins, and taking advantage of the browser's existing support for form submission.
So how to do that? I chose to stick with the existing HTML4 form, fieldset, input, select and button elements, and to consider what new attributes could provide the desired behavior. In essence, this meant grafting attributes taken from the XForms bind element on to the HTML4 input element. Thus type, pattern, constraint, required, relevant, and calculate. The idea is that the XForms model and associated constraints can then be readily generated from the HTML elements.
The HTML input element already defines a type attribute so it was a matter of adding new values, and my experiments looked at doing so for number and date. This worked fine on most browsers, but the Opera browsers handling of the type and required attributes made it necessary to support datatype and needed as alternatives. I borrowed min, max and step from Web Forms 2.0 for use with an experimental range control. I also implemented min and max to work with dates, but didn't get as far as implementing min, max and mask as facets on strings, although I did add support for regular expressions with the pattern attribute.
The HTML forms data model in current browsers allows for repeated fields with the same name and models these as an array. This made it practical to implement repeating nodesets. The HTML fieldset element seemed like an obvious choice for a container, and I just added name and repeat-number attributes. The name is used to include the fieldset element as part of the form's object model, and you can also access the fields within a fieldset as properties of the fieldset. You thus get a hierarchical object model in parallel with the traditional flat object model for fields. The repeat-number attribute is presentational and controls the minimum number of rows initially presented in the user interface. That raises some interesting questions about the back and reload semantics for browsers, but I will leave that for a later discussion.
This leaves us with the expressions used with constraint, required, relevant and calculate. For simplicity field names can be used directly. When needed you can also use compound names corresponding to nested fieldsets. To keep the library size down, I took advantange of JavaScript's eval. This means that expressions can access global variables and functions, and this is useful for accessing author defined functions. The library currently makes use of onchanged, onfocus, onblur and onclick events on form fields, and onsubmit on the form element. Further study is needed as to whether to also support author supplied handlers for these events (i.e. set as attribute on fields and invoked after the library's default processing is done).
After a detailed study of what it takes to support new elements in existing browsers, I chose not to implement an output element. In practice, the input element can be used instead, and can be set to be read only if needed. This raises a question of how to allow user entered values to overrride the calculated value for a given field. This is used, for example, in expense claims to override the currency exchange rate. The data model needs to keep track of when an explicit value has been provided. I would like some help in understanding how this can be expressed with XForms 1.1.
How to support customizable presentation of hints and additional help for fields, for example, when the field receives the focus, or when an error is detected. The library currently copies the title attribute between the label and input elements to ensure that hovering the mouse over either results in a tool tip containing the hint. The label may be used to provide a hypertext link to additional help, but that requires the user to activate the link to view the help text. In principle, an application could display the help text in a designated pane using XmlHttpRequest (Ajax) to retrieve the text from the server. Alternatively the text could be embedded in the form, remaining hidden until revealed. One approach would be to raise XForms events that can then be trapped for customized presentations of errors and warnings. Suggestions are welcomed for ideas on how to support such mechanisms in a way that can be customized through CSS without any need to write lines of script.
How to deploy incremental extensions to HTML where some browsers provide native implementations and others rely on web page script libraries. At the minimum, there needs to be a way to determine if the browser includes native support. Better yet, would be a means to avoid loading the library if the browser has effective native support. A related issue is clarifying the object model for forms and the points of extensibility.
The current library adds and removes class values to elements as a means to indicate the state in a way that can be styled via CSS. The CSS3 Basic UI module defines new pseudo-classes such as :invalid which provide an alternative to dynamic classes, but relies on native implementation. This also raises the possibility of using CSS to specify which UI control is bound to a particular form field. For example, allowing you to choose between a text box, a text box plus spin up/down buttons, a slider etc.
When typing a value into a field the change won't effect the rest of the form until you move the focus away from the field. This is how spreadsheets work, but it might be worth considering updating the form after every keystroke, at least for numeric fields. This wouldn't be worth doing for date fields, and might be irritating for validation and relevancy purposes.
The need to enclose fields within a form element can be a problem when using tables for layout. It might be feasible for fields to instead reference the form element by its name. The library would then fix up the form object model accordingly. I have yet to test if this would really work across browsers. In any case, you are in many cases able to achieve the same layout in different ways, e.g. through using CSS.
The pattern attribute can be used to test field values against a regular expression, but it would be nice if the pattern could also be used predictively to help users with data entry. A related idea is for the field to show the fixed parts of the pattern and constrain what the user can type on a keystroke by keystroke basis.
When a group of fields is made relevant, the focus should be set to the first field. Likewise when such a group is hidden, the focus should be set to a visible field. This is an just an implementation detail that however effects usability.
In principle, XForms-Tiny could define new elements such as an <output/> element for calculated fields. In practice, this is messy to support as existing browsers vary in how they treat unknown elements. For example, Firefox and Opera ignore the /> syntax for empty elements, resulting in the need for patching up the parse tree. It is much easier to use the existing input element for calculated fields, and this has the additional benefit of enabling users to override the field's value when it isn't read-only.
There are limits to what a web page script can do on its own due to the security model under which such scripts are executed. Thus whilst XMLHTTPRequest (Ajax) could be used to submit data as as XML, it wouldn't be able to support file upload as part of the submission, since web page scripts understandably don't have access to the local file store. The Web API working group is however working on an interface for scripted file upload.
What requirements are there for a load and save interface? One possibility would be to use an XML representation of the form's data, with the fieldset names being used for structuring the data. It should be possible to extend the HTML submission mechanism to use Ajax to replace the form's data or to provide partial updates to the page's content. W3C's work on REX is likely to be relevant to achieving this goal.
A separate and complementary library is under development for exporting from XForms-Tiny to the XForms data model and associated bind elements. This will provide a transformed version of the entire Web page including the user interface controls and other content. This is a separate library to avoid a download penalty when it isn't needed.
A summary of browser bugs found during this work is provided in the hope of fixes in future releases of these browsers.
Introduction | Demos | Acknowledgements | Relationship to XForms | Open Issues
Dave Raggett <dsr@w3.org>Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.