some technical thoughts about incremental improvements to forms

On the assumption that incremental improvements to text/html is
appropriate, what middle ground is possible between HTML4/XHTML 1
and XForms? It seems worth taking a closer look.

The HTML input element is an empty element and doesn't permit label 
text as its content. With hindsight, that was probably an error.
The HTML label element was added in HTML4 and is a little awkward
to use. By contrast the XForms input is non-empty and can contain 
label, help, hint and alert elements. You can map these into HTML
as follows:

   label - use the HTML label element
   help - use a hypertext link within the HTML label element
   hint - use a title attribute in the HTML label (or a) element
   alert - use JavaScript and some creative flair

The HTML working group would like to import the XForms elements into 
the HTML namespace so that authors don't have to provide namespace 
prefixes. This presents some problems for documents delivered as 
text/html, since existing browsers would treat input as an empty 
element. This could be avoided by changing to a new element name,
or by introducing attributes in place of child elements.

New elements and new attributes on existing elements can be made to 
work on a wide range of existing browsers via a script. This has 
been demonstrated for both the XForms and WebForms proposals. There 
are some wrinkles due to browser incompatibilities that could be 
improved upon. One such is that Internet Explorer honors the
/> syntax for empty elements whereas Firefox and Opera, for
instance, do not. There are also differences in how nodeName and
other DOM Node properties work across browsers for elements
with and without namespace prefixes. These could be addressed by
the W3C Web API working group with a view to making it easier to
deploy mixed-markup documents on the Web.

XForms provides sophistocated capabilities that may seem a little
daunting at first, but which reduce the effort for developing and
maintaining forms. You have to write more markup, but you save on
hard to maintain script code. Some syntactic sugar for simpler
forms would help to ease newcomers into the mindset needed for
more complex forms. This syntactic sugar should be obvious and
easy to apply, as well as maintaining consistency with the more
general syntax.

This would seem to include the ability to set data type and value 
constraints as attributes on form fields, for example,

      type="integer"
      min="18"
      max="15"
      match="regular expression"

A variety of types have been discussed in the context of both
WebForms and XForms, so coming up with a short list shouldn't
be such a stretch. The data type also permits the use of
appropriate presentation controls such as date pickers.

For text based input fields it is convenient to distinguish
between the value typed by the user and the value that is
held internally as part of the form's data model. Doing so
makes it easier to express constraints involving such fields,
including fields showing calculated values.

This is often implemented as the model-view-controller design 
pattern, and associated with getter and setter functions to map 
between the internal and presentation formats for the data. Some 
examples of relevant data types are credit card numbers and dates. 
It would seem appropriate to define the internal formats for a small 
set of these data types.

The next question is how fields should bind to the internal data.
HTML4 uses a combination of a field name and a form where the
form is implied by the nearest enclosing form element. This is
limiting in two ways.

  a) restricted to a flat list of names
  b) nesting within form element interferes with layout

XForms breaks free of this by getting fields to reference structured 
instance data via an XPath expression. The syntax is very simple for 
simple cases and as such shouldn't present any barrier to newcomers.

Spreadsheets have proven to be very popular and include the
means to:

  a) preinitialize field values
  b) specify field types
  c) define fields as expressions over other fields
  d) provide hints for how to fill them out

It would be valuable to support all of these in a simple manner for 
web applications. Fields that show calculated values require some 
way to express the calculation. XForms uses a subset of XPath for 
this purpose. Such expressions are also useful for verifying 
integrity constraints, and for determining if some field or groups 
of fields need to be filled out based upon the values of other 
fields.

A further consideration is the relationship to the JavaScript data 
model. In VoiceXML 2.0, fields are associated with JavaScript 
variables. Structured data can be held as a hiearchy of JavaScript 
objects. It is worth thinking about the potential relationship 
between this and XForms data models. This would also make it 
practical to consider the role of JSON (JavaScript Object Notation) 
for both initialization and submission of structured data, and 
something that is popular when using Ajax. In particular, this would 
allow a direct mapping between XPath expressions and JavaScript 
expressions.

I don't think the HTML4 form element is needed, as it can be
replaced by elements that describe how and where to submit the
data. Once again, VoiceXML has something to offer as it supports
the means to name a list of fields to submit to the server.
In other words, the fields bind to an internal data model and
provide type and value constraints. The submit mechanism then
describes which set of data to submit, and in what format.

In XForms the submission element is enclosed by the model element, 
but in principle, the submission element could be on its own 
provided it has a means to reference the data to be submitted, for 
instance as a space separated list of names or XPath expressions.

Is anyone else interested in this level of technical discussion?

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

Received on Monday, 4 September 2006 10:47:13 UTC