Comparision between XForms-Tiny and WebForms 2.0
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:
<input name="total" datatype="number" readonly="readonly" calculate="sumover(expenses, amount/(rate?rate:1))">
where expenses is the name of the fieldset used for the repeating group of fields. The date field is defined as:
<input name="date" datatype="date" size="18" title="date incurred" needed="defined(amount)">
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.