Introduction | Demos | Acknowledgements | Wiki | Relationship to XForms | Open Issues | Slides

XForms-Tiny Testbed

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.

Public Wiki

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.

Further work

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:

Relationship to XForms

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.

Open Issues

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