View source for Comparision between XForms-Tiny and WebForms 2.0

__NOTOC__
This is a comparison of the XForms-Tiny proposal, see:

   http://www.w3.org/2006/11/XForms-Tiny/

   http://www.w3.org/MarkUp/Forms/wiki/XForms-Tiny

with the [[WebForms]] 2 proposal as submitted to W3C, see:

   http://www.w3.org/TR/web-forms-2/

== Summary ==

Both proposals involve incremental extensions to HTML
forms as defined in HTML4 and DOM2 HTML. XForms-Tiny includes
a much richer range of features that greatly reduce the need
for page specific scripting compared with WF2. This will effect
the relative cost of developing form-based applications with the
two proposals since Web page scripts are prone to bugs. XForms-Tiny
is also much easier when it comes to repeated groups of controls,
avoiding WF2's tight coupling to HTML tables. This is important
for device independent markup and the experience offered to users
on mobile devices.

XForms-Tiny would benefit from inclusion of a number of WF2
features, for instance, relaxation of the need to enclose fields
within a form element, the autocompletion hint, and a number of
other improvements to HTML forms, including autofocus, inputmode,
and type="time" for 12 or 24 hour time of day values. An open question
is whether the WF2 form attribute can be made to work on existing
browsers or whether it necessitates native implementation support.
WF2's output element also raises challenges for implementation on
existing browsers. These issues will be investigated experimentally.

The rich declarative features of XForms-Tiny lend themselves to
exporting the XForms model and constraints for use in server-side
data validation. In principle, XForms-Tiny could also be used to
submit structured form data as XML, although this has not been
implemented as yet.

At the time of writing Web Forms 2 is natively supported by
only one browser Opera 9, but an implementation is said to be
underway for Firefox. An experimental [[JavaScript]] library is
available for adding [[WebForms]] 2 support to IE, but not for other
browsers.

XForms-Tiny works on a much wider range of browsers via a
cross-browser [[JavaScript]] library: Internet Explorer 6 and 7,
Firefox 1.5, Firefox 2, Galeon 2.01, Opera 9, Konqueror 3.5,
Safari, Opera Mobile 8.6 and [[NetFront]] 3.4, although the library
has yet to be tuned to improve the user experience on small
displays for repeating groups of fields. The compressed library
can be delivered as a 6KByte file.

The following summaries are abbreviated and you are advised
to look at the above links for more details. The XForms-Tiny
testbed includes a large number of working examples. Both
proposals can be considered as work in progress. You are
recommended to look at the examples included in both proposals.

== [[WebForms]] 2 (WF2) ==

Several new values are proposed for the input element's type
attribute. These are datetime, datetime-local, date, month,
week, time, number, range, email, and url.

These offer support for input of date and time values matching
the ISO 8601 specification. Opera 9 implements a data picker
but doesn't allow users to enter date values directly. Numbers
are floating point numbers, whilst email and url are strings
matching email addressed as defined by RFC822 and IRIs as
defined by RFC39871 respectively.

The type attibute can be used in conjunction with the new min,
max and step attributes, whose interpretation depends on the
type. For type="range" Opera 9 shows a slider without any
numerical indication of the range as specified by the min,
max and step attributes.

The accesskey, disabled and maxlength attributes apply to a
wider range of form elements.

There are several other new attributes:

 pattern
    tests the fields value against a regular expression

 required
    If present this must have the value "required" and
    indicates that the field must be filled out prior
    to submission. There is no provision for making a field
    required only when another field has a specific value.

 form
    A space separated list that names the form elements that
    the field belongs to. This avoids the need for fields to
    be contained by the form element they belong to.

 autocomplete
    This is either "on" or "off" and is used to inhibit the
    browser's autocompletion mechanism, e.g. for passwords
    and other values deemed too sensitive by the author.

 autofocus
    If present this must have the value "autofocus". This is
    used by authors to get the browser to set the focus to a
    given field (there can only be one) and ensure that it is
    visible by scrolling the page as necessary.

 inputmode
    As per XForms 1.0 specification. This is used to provide
    a hint to to the browser to provide the appropriate input
    mechanism for text in a given language, e.g. kanji.

There is a new element called "ouput" which behaves much like
span except that it is a form control. Its value can be altered
via the DOM.

The textarea element no longer requires the rows and cols
attributes. You can control wrapping behavior via the wrap
attribute. The accept attribute can be used with a MIME type
to support syntax coloring etc.

There are number of other changes to file upload controls,
and submit buttons. The form element gets a new attribute
called "replace" with values "document" and "values". The
latter is used when the body returned by the server is to be
treated a data field for prefilling form fields.

WF2 includes support for repeated groups of form fields.
This involves additional attributes on tr elements. There
is provision for adding and removing rows, and for moving
them up or down within the table.

WF2 provides the hooks for richer behaviors through scripting
but doesn't give authors much in the way of a helping hand.
For instance, you are expected to write your own handlers
to update calculated values, and to sort out the calculation
order yourself.

== XForms-Tiny ==

This was developed as a cross-browser [[JavaScript]] library,
but could also be supported natively. It started life as
"forms-lite" but changed its name after becoming adopted
as work item of the W3C Forms working group. It involves 
new attribute values for the input element's type attribute,
and a number of new attributes for various form controls,
but no new elements. A testbed and a large set of working
examples can be found at:

   http://www.w3.org/2006/11/XForms-Tiny/

The input element's type attribute is extended to support
number, date and range. For dates, a date picker is shown,
but you can also type the date directly into the input
field. The value is normalized on entry in a similar way
to spreadsheets to a human friendly format. For ranges,
the library will take advantage of the browser's native
support for a slider if available, otherwise it will
generate up down buttons. Like WF2, you can use the min,
max and step attributes.

Note that Opera's DOM coerces values for the type attribute
that it doesn't recognize to "text". This prevents the
[[JavaScript]] library from being able to access the value
provided by the author. The library therefore also supports
the "datatype" attribute as a work around. There are also
reasons for specifying the dataype separately from the
control type, e.g. to allow ranges controls to be applied
to dates (XForms-Tiny has yet to support that).

The pattern attribute can be used together with a regular
expression in the same way as for WF2 and XForms.

The calculate attribute can be used with simple [[JavaScript]]
expressions that act over form fields e.g. "x+y" to sum
the values of two fields named "x" and "y". The library
uses a topological sort to determine the calculation order.
This makes it practical to use HTML as a replacement for
spreadsheets. Expressions can include user defined
functions, e.g. for the price of particular items. 

In the absence of an output element, you can use calculate
with a regular input element, which can be marked as
readonly as per the HTML4 specification. Adding support
for new elements to old browsers is tricky due to variations
between browsers in how they handle unexpected elements.

The constraint attribute can be used with simple [[JavaScript]]
expressions. If it evaluates to false, then the field is
considered to be invalid.

If the field fails any of its validation tests for the
type, min, max, step, pattern or constraint attributes it
is marked as invalid. The library dynamically adds the
"invalid" class value to affected fields, which can then
be used via CSS to style such fields accordingly. The
testbed sets the field background to a reddish color.
The same approach is used to indicate that a field has
the focus, is missing a required value, is disabled or
read only. The testbed stylesheet, for example, includes:

 input { text-align: center; background-color: transparent }

 input[type="text"] { background-color: white }

 input.readonly { color: blue;  background-color: rgb(245,240,245) }

 input.focus { background-color: rgb(230,230,245) }

 input.invalid { background-color: rgb(255,230,245); color: red }

 input.irrelevant { display: none; visibility: hidden }

 input.missing { background-color: rgb(255,230,245); color: red }

CSS3 defines equivalent pseudo-classes e.g. :invalid, but these
won't work with existing browsers as they require native support.

The required attribute can be used together with a simple
[[JavaScript]] expression to indicate the conditions under
which a field must be filled out, e.g. depending on the
value of another field. The expression is evaluated when
the user attempts to submit the form. See the following
test example:

   http://www.w3.org/2006/11/XForms-Tiny/7/

Note that Opera's DOM coerces values for the required attribute
to "required". This prevents the [[JavaScript]] library from being
able to access the value provided by the author. The library
therefore also supports the "needed" attribute as a work around.

The relevant attribute can be used to suppress irrelevant
fields or groups fields. It is used with a simple [[JavaScript]]
expression that can range over field values or user
supplied functions.

The fieldset element can be used for repeating groups of
fields. The repeat-number attribute specifies the minimum
number of "rows" that are shown. You include the labels
and the fields and leave it to the implementation to do
the rest. The testbed generates a table with the labels
across the top, but a more refined implementation would
show one row at a time on a device with a small display,
along with a means to move between rows.

The label attribute can be bound to fields by id or by
name. This allows a label to be used for a repeated set
of fields with the same name. The id value takes precedence
when it comes to making a match.

To initialize fields within a repeating group, you simply
include the corresponding fields as needed. Empty fields
are added below in the case where you provide less than
the number indicated by repeat-number.

XForms-Tiny defines incremental extensions to the DOM,
e.g. tracking which fields belong to each fieldset.
XForms-Tiny allows you to use fieldset names to quality
which fields you are referring to. The testbed includes
an example, where the town a shipment will be delivered
to is bound to either the billing or shipping address
according to whether the two are the same or different.
See:

    http://www.w3.org/2006/11/XForms-Tiny/14/

A form to entering expenses made in foreign currencies provides
a more complex example of XForms-Tiny. It includes date pickers
and selection lists as part of the repeating group of fields
used to entering expenses. See:

    http://www.w3.org/2006/11/XForms-Tiny/18/

If you enter values into several of the amount fields in the
rightmost column and press the submit button, you will see that
the column headings and the field backgrounds for missing field
values will be highlighted in red. The column labels remain
highlighted until all of the effected fields in that column have
been filled out. If you now use the browser's view source feature
to look at the markup, you will see that firstly, that the only
script is the XForms-Tiny library, and secondly, the use of the
"needed", "datatype" and "calculate" attributes for the form's
logic, e.g. the total amount field at the bottom of the form is
marked up as:

 &lt;input name="total" datatype="number" readonly="readonly"
  calculate="sumover(expenses, amount/(rate?rate:1))"&gt;

where expenses is the name of the fieldset used for the repeating
group of fields. The date field is defined as:

 &lt;input name="date" datatype="date" size="18"
  title="date incurred" needed="defined(amount)"&gt;

A complementary [[JavaScript]] library has been written to
explore the means for exporting the XForms user interface
controls, model and instance. This would make it easy for
authoring environments to automatically generate the server
side code for validating submitted data. A further idea would
be to extend XForms-Tiny to support submitting stuctured form
data as XML, using Ajax to transfer the data on existing
Web browsers.

The XForms-Tiny proposal is still being refined and is expected
to add support for incremental updates of calculated fields on
a keystroke by keystroke basis, and a means to specify the
precision with which calculated values are presented. Other
features under consideration include support for manual overrides
of calculated fields, interfaces for adding, deleting and moving
rows, and the means to dynamically load and save forms without
necessitating a page load. The proposal could also be extended to
cover autocomplete and a number of other features in WF2.

The goal of using native implementations when available, and
falling back to a script libary when not, depends on there
being a reliable way to test for native implementations.