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

Forms Lite 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 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.

Forms-lite is a series of experiments that explore incremental extensions to HTML4 forms using a cross browser script library that interprets the extensions, and which works on widely available browsers such as Internet Explorer 6 and 7, Firefox, Opera, Konqueror and Safari. The experiments are intended to explore opportunities for stepping stones between the capabilities provided by HTML4 and those 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. All this should be possible without the author needing to write any lines of client-side script.

The forms-lite 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 focussed field, and to hide irrelevant groups of fields.

Here is a list of demonstrators for different aspects of forms-lite:

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 under 6 KBytes (minified version).

I am considering adding support for using Ajax to load and save form data as XML, and for reflecting changes without waiting for the onchanged event. The library has yet to be extensively tested, and 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.


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

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 making use of the browsers 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

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


Dave Raggett <>