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 <[EMAIL PROTECTED]> http://www.w3.org/People/Raggett
