[whatwg] forms-lite testbed

[Dave Raggett]

As promised, I have been working on a series of experiments on 
incremental extensions to HTML forms with a view to stimulating 
thinking about potential improvements that go well beyond the 
WebForms 2.0 proposal, reducing the need for scripting whilst 
remaining very simple to author, even for complex forms.

You can explore the testbed at:

      http://people.w3.org/~dsr/forms-lite/

This demonstrates experiments on several new attributes for the
HTML input and fieldset elements. It should be straightforward
to transform into the XForms markup if needed. This work reuses 
attribute names proposed for WebForms 2.0 and XForms where 
practical. It raises the issue of how to deploy extensions to
HTML where some browsers have native support and others rely
on web page scripts to support the extensions.

The examples use a JavaScript library to interpret the additional
attributes and seems to work on IE, Firefox and Opera, but see
the caveats at the end of this email. The library has yet to see
extensive testing so be gentle and please report any problems you
find. I hope to add support for using Ajax to load and save forms
as XML, and to export the markup for the XForms data model.
The library can be deployed as a 6 Kbytes gzipped file and as
such isn't onerous on desktop browsers. It is released as freeware
under the terms of W3C's software license.

Here is a summary of the new attributes and what they do:

  calculate
    This is used with the input element for spreadsheet like
    formulae for calculated fields, e.g. calculate="x+y" where x
    and y are names of other form fields. The forms-lite library
    takes care of the dependencies between calculated fields using
    a topological sort.

  pattern
    This is used with the input element to constrain input to
    match a regular expression.

  additional values for the input type (or datatype) attribute
    In particular, number and date. For dates, the value entered
    by the user is converted into a standard form, e.g. 11 oct 2006
    becomes "Wed, 11 Oct 2006". In principle the date type could
    be used with a browser provided date picker.

  min and max attributes
    These are both used on the input element in conjunction with
    the number or date types, and constrain the value to be
    between the min and max values supplied with these attributes.

  range and step
    When the type attribute on the input element is set to
    "range", the user interface changes to allow the user to
    select a value between min and max, at increments defined
    by the step attribute. The library can be customized to alter
    the user interface associated with the range control.

  validate
    The validate attribute is used with the input element to
    supply an expression over form fields that evaluates to
    true or false, e.g. <input name="y" type="number"
    validate="y > x"/> which says that this field value
    must be greater than the value of the field named "x".

  required (or needed)
    This is an expression like validate but requires the user
    to have filled out a value for the field. The library
    evaluates expressions by first rewriting them and then
    calling the JavaScript eval function.

  relevant
    This may be used on HTML input and fieldset elements to
    indicate when the associated group of fields is relevant.
    It is an expression similar to validate. The library
    dynamically adds or removes class values so that the style
    sheet can be used to hide the fields when they are shown
    to be irrelevant. Such fields are not included when the
    form is submitted.

  repeat
    This attribute is used on the fieldset element when the
    associated controls form part of a repeating group, e.g.
    as in a sequence of line items in a purchase order.

It so happens that Opera 9 has implemented WebForms 2.0 in such a 
way that causes problems for using the required and type attributes. 
My work around is to also support the use of "datatype" as a synonym 
for "type", and "needed" for "required".

I have dynamically added and removed class values to reflect the 
current state of form fields. In principle, this could be replaced 
by the pseudo classes defined by the CSS3 Basic User Interface 
module, e.g. :invalid and :read-only, although these would need a 
native implementation to support them. See:

    http://www.w3.org/TR/css3-ui/

I would also like to see CSS support for determining which
user interface control is used e.g. a slider with a numeric
display or a text box with spin up/down for range controls,

In closing, note that this is experimental work and hasn't been 
subject to the rigorous testing needed for commercial products.
My aim is to continue to improve the library as I become aware of 
problems. If you are interested in helping with testing and further 
development please let me know.

  Dave Raggett <dsr at w3.org>  http://www.w3.org/People/Raggett